Re: tracking OpenGL support for specific boards
>> What would help further would be for such information having references >> to sources, and each information point be referencable (not only the >> dataset as a whole). > Isn't this already done for us here? > https://gpuinfo.org/ I don't see any reference to sources. Also I see it as "Ubuntu" and "Arch" as OSes, whereas I'd rather see the status of the underlying driver so I can easily extrapolate from it to what will happen in any particular GNU/Linux distribution. The database describes itself as "an online tool for developers that want to check out GPU hardware capabilites", so it seems to be focused on hardware, whereas I think we need something that focuses on the drivers. Stefan
Re: armel after Stretch
> jenkins.d.n would be the place to put full-system cross-grading tests. > piuparts would be the place to put per-package cross-grading tests. FWIW, I just went through a cross-grade of a Lil'Debi chroot from armel to armhf. I wouldn't recommend it to someone who's not used to command line use of dpkg and apt. But it worked nicely in the end (the get-selection/set-selection step seemed to create trouble more than anything, OTOH). Stefan
Re: Libre graphics could become the standard if we push right now
>> So I think it is very important that we support AMD right now on what we >> can, and ask manufacturers to include AMD graphics in those products. > You do realize that AMD graphics need proprietary firmware to have > proper 3D acceleration without which you probably couldn't run any game > at all - so goodbye Libre graphics. That's still much better than the situation with Nvidia. But your point is well taken: we should put most pressure on Nvidia while keeping the pressure on AMD. Stefan
Bug#803303: general: Standardized troubleshooting
Package: general Severity: wishlist Dear Maintainer, I've been using Debian on all my machines for many years and am generally very happy with it but I recently realized that my experience could have been even better (both for me and for the maintainers of all the packages I use) if it were easier to figure out how to troubleshoot problems. Concrete suggestion: add a "TROUBLESHOOTING" section in the manpage of every program, explaining how to get more info about what's going on when the program doesn't do what the user wants. I've often gone through steps like: 1- Program Foo crashes/hangs/misbehaves/younameit when I do something. 2- Search the web to see if someone else bumped into the same problem and found a fix for it. 3- No luck, so I report the bug to Debian or to the upstream. 4- Someone gets back to me telling me to set env-var FOO_DEBUG=99 then re-run the program and show her what is reported in file .foo_debug_log. My suggestion is to try and skip step 3 and 4, replacing them with "man foo; then look for the TROUBLESHOOTING section". Usually this troubleshooting info can be found somewhere, but every program puts it at a different place, making it difficult to find. Furthermore, the troubleshooting info needed may go further than the program itself, e.g. when the program is not started from the command line but via some other mechanism (inetd, systemd, gnome-shell, ...). In the longer run, it would be even better to try and standardize not just the place where the troubleshooting info is located, but the way troubleshooting is done (e.g. always provide a "--troubleshoot" command-line flag which always gives the output at "the same place"), so that I could for example do "systemctl troubleshoot gdm3" and systemd would know how to start gdm3 in order to get debugging info. But a good first step seems to be to start collecting the troubleshooting info at a standardized place (e.g. the manpage). Of course if you prefer putting that info in /usr/share/doc//TROUBLESHOOTING, that's fine as well. As long as it's always the same place. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: [ltp] Re: double checking Debian's 686-pae vs. -486 probe
Say, for the sake of sharing a single .deb offline, what bad thing might happen if I run the -486 kernel on my other machines where I could run the -pae kernel? Nothing serious, unless they have a lot of RAM (in which case the kernel may not be able to make use of all of it). And you lose NX too. I wouldn't lose any sleep over it. Stefan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/jwvmxicfauw.fsf-monnier+gmane.linux.hardware.think...@gnu.org
Bug#548661: dpkg: Override package dependencies
reassign 548661 apt thanks But as seen in bug#542095, some dependencies are not really hard, yet you don't want them to be recommends because that would be too easy for users to ignore. So bug#542095 shows that there is a need for something between recommends and true dependencies that can only be ignored if the user very specifically requests to ignore this precise dependency (I already ignore all recommends). I don't agree that we need something in between. You decide what you want to install. the gnome meta-packages doesn't correspond to what you want? don't install it and install the various components by hand or create an alternative meta-package. While it's not too difficult to install some of the components by hand (aptitude show gnome makes it easy to see which components are needed), doing it leads to lots of headaches in the long run, since when new components come around, nothing will tell you about it (and even less install them for you), and when old ones become replaced or obsolete, agai nobody will tell you (and even less install the replacement for you). That's what the `gnome' package is for, and that's why it's important to be able to install that package (and other metapackages) rather than its dependencies. You come up with this request only because Josselin Mouette doesn't want to drop network-manager to a Recommends or put an alternative in place. Actually, no. It's a kind of problem that has shown up several times already in the past, for various reasons. Sometimes it's just a bug in the packaging other times the maintainer has good reasons to keep the dependencies in a particular way, even if they don't fit my needs. Clearly, the current network-manager-in-gnome issue is the one that prompted this bug-report, but only because it finally occurred to me that a good solution to this problem is a more general solution that gives more power to the end-user. The solution exists but because the maintainer doesn't want to implement it, you request a third way to respond to your need under control of the user. How is that reasonable? Because in the world of Free Software, last I heard, giving more control to the end user is generally considered a good thing, so she doesn't have to rely on the goodwill/agreement/help of the men in charge. What alternative solution do you propose if I want to both have wicd and gnome installed? Or if my system is memory constrained and I want xserver-xorg installed but not hal? Or ...? gnome is not required at all, it's only a meta-package, don't install it but install manually all the other dependencies. For the xserver, talk to the X maintainers or use a lighter distribution. So for each problem in the packaging dependencies, you advocate to use a different solution, each one of those with its own set of problems. Instead, I advocte a single solution that can solve each one of those problems in a uniform manner: tell the packaging system (I originally thought dpkg would be a good place for that, but I now realize that APT is a better place for it) about some constraints that need to be ignored. This could include not only Dpends-constraints (as suggested originally in this bug-report), but also Conflicts-constraints (e.g., so I can install grub-pc, grub-efi-amd64 and and grub-efi-ia32 on my Debian rescue USB key). Clearly, ignoring such constraints is risky business (not like ignoring recommends constraints), so you'd want to force the user to think hard before doing so, and you'd only let her ignore specific constraints, you might ask for confirmation before adding such an ignore-constraint to the list of ignored constraints, and you might even query the user every once in a while to make sure she still wants to keep those ignore-constraints. Stefan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
