Bug#868013: ITP: dh-fortran-mod -- debhelper add-on to handle Fortran '.mod' files
Package: wnpp Severity: wishlist Owner: Alastair McKinstry * Package name: dh-fortran-mod Version : 1.0 Upstream Author : Sebastien Villemont * URL : http://anonscm.debian.org/gitweb/?p=debian-science/packages/dh-fortran-mod.git * License : GPL3 Programming Lang: Perl Description : debhelper add-on to handle Fortran '.mod' files Modules were introduced in the 1990 revision of the Fortran standard. When the Fortran compiler processes a source file containing a module, it produces both an object file and a '.mod' file. The latter plays a role similar to header files in C, since it is needed when compiling other source files which make use of the module. . The '.mod' files are however platform dependent, and their format changes with the gfortran version . This package provides the dh_fortran_mod command, which simplifies th inclusion of '.mod' files in binary packages. First, it places the '.mod files in the correct platform- and gfortran-dependent location. Second, it adds the right dependency information on gfortran version(s). . Inclusion of dh_fortran_mod in dh sequence is also provided under the name 'fortran_mod'. . This package was originally developed by Sebastien Vilemont.
Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system
Samuel Thibault writes: > Vincent Bernat, on lun. 10 juil. 2017 20:55:29 +0200, wrote: > >> Other major distributions are using this new scheme (notably Ubuntu >> which has no reason to have users smarter than ours) > > The reasoning is the converse: non-techy users will just not be exposed > to interface names anyway. Debian users, however, tend to be more techy, > and do see these interface names. And basically *all* documentation > before this interface name change is now incomprehensible to techy > beginners. Not only old docs, unfortunately. The change makes it impossible to describe system independent procedures involving a network device. As an example, I happen to get a few questions regarding LTE modem configuration. Most of these users will have a single modem, so I know the kernel network interface name is 'wwan0'. Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now? Depending on how "techy" the user is, I may have to write more about netdev naming policies than the real issue. This isn't something I just made up. It is a real problem for me. And I only see a fraction of the problem. I can imagine the issues for those attempting to write any docs touching Linux networking.. > I'm really worried here: this change, like a lot others done recently, > is making the Linux ecosystem yet more complex to understand, thus > raising the barrier for techy beginners yet higher. Yes. And what is most worrying is all the excuses made, often claiming the opposite. We are all going to laugh at enp0s31f6. But it looks like we are looking at a couple of years of breakage first, before the advocates move on to some other shiny project where they can solve a problem that didn't exist before they entered the scene. Bjørn
Naming of network devices - how to improve it in buster
Ok, it should be clear now that the new way of naming interfaces is not ideal, but the older ways weren't either. Let's have a look at what we want: - A simple name for systems with a single Ethernet and/or Wireless interface (the simple desktop/laptop scenario). - A consistent naming scheme for interfaces in a system with multiple Ethernet interfaces (the server scenario). - Not having interface names change after reboots. It should work well in the following scenarios: - Installing on a desktop/laptop. - Installing on a server. - Installing in a VM. - Installing using debootstrap. - Cloning a system. The pros/cons with the various solutions: - State file: - PRO: Once an interface has a name, it keeps that name on the same system. - CON: Does not work well when debootstrapping (it can copy the host config, when the intent is to run the deboostrapped filesystem on a different machine). - CON: Does not work well when cloning a system. The issue in both CONs is that eth0 for example is bound to a MAC address that is not used in the new system, so the new system gets eth1 for its Ethernet interface. - Stable udev names: - PRO: Reliable names when installing on identical machines. - PRO: Handles cloning a system well. - CON: Can results in overly complex interface names. - CON: Does not handle changes in bus topology. So, what can we do to improve the situation and get the best of both worlds? -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Re: Naming of network devices - how to improve it in buster
Guus Sliepen writes: > Ok, it should be clear now that the new way of naming interfaces is not > ideal, but the older ways weren't either. Let's have a look at what we > want: > > - A simple name for systems with a single Ethernet and/or Wireless > interface (the simple desktop/laptop scenario). > - A consistent naming scheme for interfaces in a system with multiple Ethernet > interfaces (the server scenario). > - Not having interface names change after reboots. I got to ask: Why? We do not have stable names for e.g. disks. Why do we need it for network devices? Yes, yes, I know you can screw up your system by configuring a dynamic device name in /etc/network/interfaces. But I believe you should be allowed to. Just like you can screw up your system by referring to a dynamic block device name in /etc/fstab. Leave the kernel network device names alone. Let them be dynamic. Just document that fact. "stable device name" is not the problem. The problem is associating configuration with the correct physical device. Note that this is not an issue at all until you add some static network configuration. Which makes it a non-issue for most end user systems, regardless of the number or type of of network devices. For static network configurations on systems with multiple interfaces, the correct and only logical place for the device association is with the rest of the network configuration. If you use NetworkManager, then it is up to NetworkManager to match it with a specific network device - if required. The rest of the system does not need to care. The remaining problem is to make ifupdown do device matching on other (and hopefully more stable) attributes than the device name. Bjørn
Re: Naming of network devices - how to improve it in buster
On Tue, 11 Jul 2017 12:14:59 +0200
Guus Sliepen wrote:
>
> So, what can we do to improve the situation and get the best of both
> worlds?
>
systemd.link(5) describes a NamePolicy option for interface names.
I would suggest to introduce a new policy "keep" to stick with
the native interface names assigned by the kernel ("INTERFACE",
see "udevadm info /sys/class/net/eth0", for example).
Advantages:
- its easy to configure (much better than using kernel command
line options
- easy to implement (hopefully)
- you can still have the reproducible interface names, even if you
have only one NIC
Please note that systemd.link is read by udev, i.e. it is not bound
to systemd.
Regards
Harri
Re: Naming of network devices - how to improve it in buster
Am 11.07.2017 um 12:14 schrieb Guus Sliepen: > Ok, it should be clear now that the new way of naming interfaces is not > ideal, but the older ways weren't either. Let's have a look at what we > want: > > - A simple name for systems with a single Ethernet and/or Wireless > interface (the simple desktop/laptop scenario). How would you determine that a system will only ever have a single interface? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#868044: ITP: vim-airline -- Lean & mean status/tabline for vim that's light as air
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: vim-airline Version : 0.8-1 Upstream Author : Bailey Ling * URL : https://github.com/vim-airline/vim-airline * License : expat Programming Lang: vimconfig Description : Lean & mean status/tabline for vim that's light as air vim-airline provides a themable vim status bar that makes use of the powerline font. It's similar to vim-powerline, but is still maintained and much simpler since it user pure vim configuration instead of scripting languages. . Some of its features: . * Tiny core written with extensibility in mind * Integrates with a variety of vim plugins * Looks good with regular fonts and provides configuration points so you can use unicode or powerline symbols * Optimized for speed; it loads in under a millisecond
Bug#868045: ITP: vim-airline-themes -- official theme collection for vim-airline
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: vim-airline-themes Version : git-master Upstream Author : Bailey Ling * URL : https://github.com/vim-airline/vim-airline-themes * License : expat Programming Lang: vim-config Description : official theme collection for vim-airline Includes the official theme bundle for vim-airline. vim-airline is a vim extension that provides a themed statusbar that can make use of the powerline characters.
Re: Naming of network devices - how to improve it in buster
On Tue, 11 Jul 2017 at 13:45:25 +0200, Bjørn Mork wrote: > I got to ask: Why? We do not have stable names for e.g. disks. Why do > we need it for network devices? We do have stable names for disks: look in /dev/disk/by-* and you'll see a bewildering variety of ways to refer to the same disk or partition. The thing that is different for network devices is that network devices are not files (device nodes), so udev cannot create a symlink /dev/network/by-mac/01:23:45:67:89:ab -> /dev/network/eth0 or whatever. Network devices are (as far as I know) the only class of device managed by udev that is not backed by a device node, which means udev cannot provide multiple equivalent names for the same device, and is forced to choose exactly one of those names, and rename the device if the chosen name is not the kernel-generated one. That is why naming network devices is, and has always been, more controversial than naming disks: they are the one device class in Linux that violates the Unix design rule-of-thumb "everything is a file". If network devices were files, udev wouldn't have a configurable NamePolicy to rename them: it would just provide symlinks for all the possible naming policies, and let the sysadmin use any, all or none of those names when configuring tools like ifupdown. Unfortunately, that isn't possible. Relatedly, network device name lengths are limited to the length of some arbitrarily-sized struct field in the kernel ABI, which is why some of the names udev can generate are so cryptic - they have to pack enough information to uniquely identify a device into a very small space. Again, compare with disks, where the names can be as long as you like. As long as the kernel represents network devices as some unique network thing that is not a device node in the filesystem, how to name them is always going to be an ugly compromise, and someone is always going to be upset by the default. Happily, there is enough configuration that those with Strong Opinions can name their network devices in any way of their choice, with one notable exception: names from the kernel's various namespaces (eth0, wlan1, wwan2) can only be reliable if no renaming at all is taking place (which is one of the options available in configuration). > For static network configurations on systems with multiple interfaces, > the correct and only logical place for the device association is with > the rest of the network configuration. If you use NetworkManager, then > it is up to NetworkManager to match it with a specific network device - > if required. The rest of the system does not need to care. This seems a good plan. NetworkManager and systemd-networkd (what I personally use on laptops/desktops and servers, respectively) both have approximately this approach. > The remaining problem is to make ifupdown do device matching on other > (and hopefully more stable) attributes than the device name. ... or alternatively, not use ifupdown, which was designed for a rather different era of networking, in situations where it's unsuitable? ifupdown served us well for many years as a competitor to Red Hat sysconfig and SUSE YAST, but those other distributions have moved on and perhaps so should we. Maybe it's time to admit that using a Debian-specific network configuration format/infrastructure by default[1] has become more bug than feature? S [1] For desktop systems, ifupdown is already only arguably the default: if debian-installer is installing NetworkManager, it configures ifupdown to only bring up lo so that NetworkManager can do the rest; but our default init system (systemd) would bring up lo anyway, so ifupdown is redundant. Subsequently replacing pid 1 with sysvinit is of course supported, but anyone who is contemplating doing so had better know what they are doing, to an extent where defaults are not entirely relevant.
Bug#868050: ITP: golang-github-shibukawa-configdir -- Configuration directories handling for Go
Package: wnpp Severity: wishlist Owner: Diego M. Rodriguez * Package name: golang-github-shibukawa-configdir Version : 0.0~git20170330.0.e180dbd-1 Upstream Author : Yoshiki Shibukawa * URL : https://github.com/shibukawa/configdir * License : Expat Programming Lang: Go Description : Configuration directories handling for Go configdir is a library for transparently accessing files under configuration directories or cache directories regardless of the operative system's convention.
Re: Naming of network devices
* Vincent Bernat [170710 16:25]:
> ❦ 10 juillet 2017 15:53 -0400, Marvin Renich :
>
> >> > With the new scheme, if I want to rename the interface to something more
> >> > meaningful, ..., and type all of
> >> > that information by hand, hoping I type everything correctly.
> >>
> >> Have a look at systemd.link(5) which enables you to do that without
> >> debugging udev.
> >
> > Okay, I had a look...
>
> Not really.
>
> In /etc/systemd/network/whatever.link, put:
>
> #v+
> [Match]
> MACAddress=00:11:22:33:44:55
>
> [Link]
> Name=em0
> #v-
>
> Note the manual page has a similar example. I don't see exactly how this
> is more complex than the udev rules we had:
>
> #v+
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> ATTR{address}=="00:11:22:33:44:55", ATTR{type}=="1", KERNEL=="eth*",
> NAME="em0"
> #v-
How does that help with ensuring that I type the MAC address correctly,
which was my point above? With the state file, udev puts the correct
information in the file for me; I only have to change the interface
name.
Your answer did not address my concern.
> > BTW, there seems to be a typo in the man page: it refers to a
> > /run/systemd/network directory; should that be /run/systemd/netif/links?
> > I'll leave you to file a bug if appropriate.
>
> No, it seems correct. All systemd-related stuff look at /lib/systemd/X
> (shipped with a package), /run/systemd/X (added by a third-party
> program) and /etc/systemd/X (added by the user).
Okay, the system I looked at (which was installed about six weeks prior
to stretch release) does not have a directory named
/run/systemd/network, but it does have an empty directory named
/run/systemd/netif/links. Is this directory for something different,
or did the directory name change between my install and the release?
> > I don't get this at all. The previous behavior was neither unreliable
> > nor unpredictable (unless you are talking about much older systems
> > before persistent-net.rules).
>
> It was unreliable. Google for "eth0_rename", you'll get ton of examples
> of people with hosts that don't boot reliably because of the inherent
> race conditions. Udev people didn't invent all this just to get people
> pissed. They have fixed a real problem.
Okay, but in a previous message in this thread you said that using a
prefix other than the one automatically assigned by the kernel would be
a trivial fix for this bug. This is a bug in the implementation, not in
the design.
> > You have completely sidestepped the question, which is about the
> > relative importance of the two goals, simple names _all the time_ vs
> > avoiding a state file. The previous behavior sacrifices the second,
> > much less important goal in favor of the first. The new behavior
> > sacrifices the first in favor of the second. Until you address this
> > issue, all your explanations look like attempts to ameliorate bad
> > behavior.
>
> Predictable names are more important to me. Simple name should also work
> for most people (using the eno*) scheme. Maybe it's not available as
> widely as it should be.
You are again answering the wrong question by conflating predictable
names with the new scheme. If the bug in the state file mechanism were
fixed, it would give names that are just as predictable as the new
scheme, but they would always be a short prefix followed by a single
decimal number. I have not said in this thread that the prefix must be
"eth", just that it must be simple. I would be happy with names like
en1, en2, wl1, and wl2. I don't care if the numbering starts at 0 or 1.
If we can _always_ have simple names and at the same time ensure that on
reboot, the same interface always gets the same name, that is much,
much, much more important than avoiding a state file. The new scheme is
guaranteed to give awkward-to-use names in at least one common
situation. The old way has one known bug in which the rename fails.
There is a known fix for that bug. With the bug fixed, the old way also
gives predictable names, but the names are always simple, rather than
occasionally being simple, sometimes being not so simple but not so
complex, and sometimes being very awkward.
The presence or absence of a state file makes very little difference.
If it can be avoided without sacrificing simple names, that's great.
But if avoiding a state file means that sometimes the names must be more
complex, it is not worth the cost.
Again, your answer does not address my concern about a common case where
the new scheme gives awkward names. This concern is clearly shared by
others, as seen in this thread and past threads. This concern has never
been adequately addressed in any thread of which I am aware.
...Marvin
Re: Naming of network devices - how to improve it in buster
On Tue, Jul 11, 2017 at 9:18 AM, Simon McVittie wrote: > On Tue, 11 Jul 2017 at 13:45:25 +0200, Bjørn Mork wrote: > > I got to ask: Why? We do not have stable names for e.g. disks. Why do > > we need it for network devices? > > We do have stable names for disks: look in /dev/disk/by-* and you'll see > a bewildering variety of ways to refer to the same disk or partition. > > The thing that is different for network devices is that network > devices are not files (device nodes), so udev cannot create a symlink > /dev/network/by-mac/01:23:45:67:89:ab -> /dev/network/eth0 or whatever. > Network devices are (as far as I know) the only class of device managed by > udev that is not backed by a device node, which means udev cannot provide > multiple equivalent names for the same device, and is forced to choose > exactly one of those names, and rename the device if the chosen name > is not the kernel-generated one. That is why naming network devices is, > and has always been, more controversial than naming disks: they are the > one device class in Linux that violates the Unix design rule-of-thumb > "everything is a file". > Is there any (technical) reason why there isn't a kernel mechanism for an "alias" for interfaces that is roughly equivalent to symlinks for files? > If network devices were files, udev wouldn't have a configurable > NamePolicy to rename them: it would just provide symlinks for all the > possible naming policies, and let the sysadmin use any, all or none of > those names when configuring tools like ifupdown. Unfortunately, that > isn't possible. > > Relatedly, network device name lengths are limited to the length of some > arbitrarily-sized struct field in the kernel ABI, Feature request to bump the size of of interface names struct? Any reason to not do so? I know that kernel solutions to our problems isn't a quick fix, but it seems that having interface aliases would allow both camps to be happy. Sorry if the answers to these questions is obvious. -m
Re: Naming of network devices - how to improve it in buster
On Jul 11 2017, Michael Biebl wrote: > Am 11.07.2017 um 12:14 schrieb Guus Sliepen: >> Ok, it should be clear now that the new way of naming interfaces is not >> ideal, but the older ways weren't either. Let's have a look at what we >> want: >> >> - A simple name for systems with a single Ethernet and/or Wireless >> interface (the simple desktop/laptop scenario). > > How would you determine that a system will only ever have a single > interface? I don't think it's necessary to do that automatically. On most systems with multiple interfaces of the same kind, the admin will know about it and can explicitly enable the extra functionality that is needed to get stable names in that situation. Best, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Naming of network devices - how to improve it in buster
Simon McVittie, on mar. 11 juil. 2017 15:18:26 +0100, wrote: > Network devices are (as far as I know) the only class of device managed by > udev that is not backed by a device node, which means udev cannot provide > multiple equivalent names for the same device, Couldn't that be what should be fixed, i.e. a kernel interface to define interface aliases? Samuel
Re: Naming of network devices - how to improve it in buster
Matt Zagrabelny, on mar. 11 juil. 2017 09:53:58 -0500, wrote: > Relatedly, network device name lengths are limited to the length of some > arbitrarily-sized struct field in the kernel ABI, > > Feature request to bump the size of of interface names struct? Any reason to > not do so? One reason is that it's already compiled in a lot of applications through the IFNAMSIZ and IF_NAMESIZE macros (8155 and 939 results in codesearch), so a lot of software would suddently break on interfaces with long names until recompiled. Samuel
Re: Naming of network devices - how to improve it in buster
On Tue, Jul 11, 2017 at 10:12 AM, Samuel Thibault wrote: > Matt Zagrabelny, on mar. 11 juil. 2017 09:53:58 -0500, wrote: > > Relatedly, network device name lengths are limited to the length of > some > > arbitrarily-sized struct field in the kernel ABI, > > > > Feature request to bump the size of of interface names struct? Any > reason to > > not do so? > > One reason is that it's already compiled in a lot of applications > through the IFNAMSIZ and IF_NAMESIZE macros (8155 and 939 results in > codesearch), so a lot of software would suddently break on interfaces > with long names until recompiled. > > Thanks for the input. This particular thread isn't the first time I've heard commentary regarding the interface name size in the kernel data structure. I'm not sure what a sensible limit is, but 16 (or 15) seems a little on the small side. Even Cisco has longer names than the Linux limit: echo -n "TenGigabitEthernet1/0/24" | wc -c 24 -m > Samuel > >
Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system
On Tue, 11 Jul 2017, Bjørn Mork wrote: > Previously I could ask a user to do e.g. 'ifconfig wwan0'. Now? sudo ip link; sudo ip addr; and probably also: sudo iw dev|awk '/^phy/'|xargs -IIFACE sudo iw IFACE info -- Don Armstrong https://www.donarmstrong.com What I can't stand is the feeling that my brain is leaving me for someone more interesting.
Re: Naming of network devices - how to improve it in buster
On Tue, Jul 11, 2017 at 01:45:25PM +0200, Bjørn Mork wrote: > The remaining problem is to make ifupdown do device matching on other > (and hopefully more stable) attributes than the device name. This is not impossible to do. I actually have some code to make ifupdown use interface matching, I'm afraid I was too late in the stretch cycle to have a well-tested implementation. I will try to add this early in buster so it can be tested properly and any kinks resolved. It's not completely trivial to implement since there are many places where interface names are used (auto , iface , inherits , and on the commmand line), the kernel allows names like "eth*", et cetera. And being consistent with other network configuration systems like NetworkManager and systemd would be nice too. -- Met vriendelijke groet / with kind regards, Guus Sliepen signature.asc Description: PGP signature
Bug#868061: general: Sleep not reliable
Package: general Severity: important Dear Maintainer, sleep mode is not reliable. My Notebook wakes up in my bag and heats up to insane temperature. This could destroy my notebook, the life time is definitely shortend. -- System Information: Debian Release: 9.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Crossgrading in stretch
Anyone have recently done a Crossgrading in stretch? Do you want to share your experience? I have followed the instructions https://wiki.debian.org/CrossGrading, more or less, and done the crossgrade from 32bits to 64bits. I managed to successfully crossgrade X11 and Mate desktop to 64bits. Some problems with mate but nothing major. As my environment is now a mix 32bits/64bits I have some problems that I will submit bug reports after I understand better the multiarch. For now I just want to share my experience. Kind regards Jose M Calhariz -- -- Fatos não cessam de existir se forem ignorados. -- - Aldous Huxley signature.asc Description: PGP signature
Bug#868061: general: Sleep not reliable
tags 868061 + moreinfo thanks Hi Oliver, > sleep mode is not reliable. My Notebook wakes up in my bag and heats up > to insane temperature. This could destroy my notebook, the life time is > definitely shortend. I'm sorry to hear the potential damage to your laptop. I think you need to provide a quite a few more details though so someone can help you. For example, the make/model of your laptop, perhaps lspci -vv, etc. etc. You may even want to close this bug and re-file using reportbug against the Linux kernel package. This should collect the relevant data to diagnose your issue. Regards, -- ,''`. : :' : Chris Lamb, Debian Project Leader `. `'` la...@debian.org / chris-lamb.co.uk `-
Processed: Re: general: Sleep not reliable
Processing commands for cont...@bugs.debian.org: > tags 868061 + moreinfo Bug #868061 [general] general: Sleep not reliable Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 868061: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868061 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Naming of network devices - how to improve it in buster
On Jul 11 2017, Simon McVittie wrote: > On Tue, 11 Jul 2017 at 13:45:25 +0200, Bjørn Mork wrote: >> I got to ask: Why? We do not have stable names for e.g. disks. Why do >> we need it for network devices? > > We do have stable names for disks: look in /dev/disk/by-* and you'll see > a bewildering variety of ways to refer to the same disk or partition. I wonder if anyone actually uses /dev/disk/by-path? > The thing that is different for network devices is that network > devices are not files (device nodes), so udev cannot create a symlink > /dev/network/by-mac/01:23:45:67:89:ab -> /dev/network/eth0 or whatever. > Network devices are (as far as I know) the only class of device managed by > udev that is not backed by a device node, which means udev cannot provide > multiple equivalent names for the same device, and is forced to choose > exactly one of those names, and rename the device if the chosen name > is not the kernel-generated one. That is why naming network devices is, > and has always been, more controversial than naming disks: they are the > one device class in Linux that violates the Unix design rule-of-thumb > "everything is a file". > > If network devices were files, udev wouldn't have a configurable > NamePolicy to rename them: it would just provide symlinks for all the > possible naming policies, and let the sysadmin use any, all or none of > those names when configuring tools like ifupdown. Unfortunately, that > isn't possible. Independent of the current discussion: why not? Is there something that would prevent the kernel from starting to provide network device nodes in /dev in some future release? It seems to me that providing a file in /dev and internally mapping this to the old device name shouldn't be that big a thing... Curious, -Nikolaus -- GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Re: Crossgrading in stretch
On Wed, Jul 12, 2017 at 2:36 AM, Jose M Calhariz wrote: > Anyone have recently done a Crossgrading in stretch? I have not, but I think it would be interesting to have automated testing of individual packages via piuparts.d.o and various default configurations via jenkins.d.n. -- bye, pabs https://wiki.debian.org/PaulWise
can't start GUI mode debian 9
Then what next? I want to use gui version (I had sent an email about the same problem, before this one )
Re: Naming of network devices - how to improve it in buster
On Tue, 11 Jul 2017 15:20:41 +0200 Michael Biebl wrote: > Am 11.07.2017 um 12:14 schrieb Guus Sliepen: > > Ok, it should be clear now that the new way of naming interfaces is not > > ideal, but the older ways weren't either. Let's have a look at what we > > want: > > > > - A simple name for systems with a single Ethernet and/or Wireless > > interface (the simple desktop/laptop scenario). > > How would you determine that a system will only ever have a single > interface? > The user knows. I think that's the major problem with these reproducible interface names: Debian never gave the user a choice between the old and the new names. Regard Harri
