Re: GCC-15 mass bug filing.

On 2025-02-18, Preuße Hilmar wrote: > I have one. Should I add a usertag: gcc-15_fault_of_qt6 ? I suggest just closing it. It does not bring any value at all. /Sune

Re: GCC-15 mass bug filing.

On 2025-02-18, Michael Biebl wrote: > I guess a bit of shell scripting around `bts close` would suffice? > That assumes of course you can somehow (automatically) determine the > list of packages that are fixed by that one popular library. I'm not sure I'm up to scripting it, but all sources wher

Re: GCC-15 mass bug filing.

On 2025-02-18, Matthias Klose wrote: > This is nothing new. See https://wiki.debian.org/ToolChain for all bugs > filed since GCC 4.9. Do you really want to have a yearly discussion to > file these bugs? The difference this year is having more than double of > the bug reports compared to GCC 1

Re: Do we need a conflict of interest policy?

On 2025-02-07, Charles Plessy wrote: > Does that mean we should equip ourselves with a Conflict of Interest > Policy? Here is a suggestion drafted by ChatGPT. I'm not sure why I should spend time reading something you didn't bother write ? /Sune

Re: handling the OpenPGP schism safely in Debian [was: Re: GnuPG 2.4 before Trixie freeze]

On 2025-01-14, Stephan Verbücheln wrote: > This appears silly from an engineering perspective, but there is a > specific motivation behind it: Proton (the mail company) wants this to > simplify the implementation of PGP with Browser APIs. But is this motivation more important than a coherent ecos

Re: handling the OpenPGP schism safely in Debian [was: Re: GnuPG 2.4 before Trixie freeze]

On 2025-01-13, Daniel Kahn Gillmor wrote: > The idea that the other members of the working group were "forcing the > schism" doesn't line up with my experience. Werner decided to step away > from the process of standardizing something in an open and interoperable > way. At some point, one might

Re: GnuPG 2.4 before Trixie freeze

On 2025-01-13, Simon Josefsson wrote: > the way you want. This is even more true considering that the people > who are patching GnuPG seems to be the same people who are working on > replacing GnuPG with Seqoia. Not only that, but some of these people were also in the standardization workgroup k

Re: Bits from DPL / Feedback on attracting newcomers

On 2024-12-11, Pirate Praveen wrote: > Thanks, in that case, it is my mistake. I was always thinking it needs > an mta configured, may be this was a recent addition. Not sure if it was > there from the beginning. It has been by default using the submission port for default for ages, though not

Re: Should l10n packages be Recommends or Suggests?

On 2024-12-05, Theodore Ts'o wrote: > Given recent discussions about depends vs recommends vs suggests > inflation, I'm thinking about down-prioritizing e2fsprogs-l10n from > recommends to suggests. I do think down prioritizing them makes sense in the current setup. Though I do also think we hav

Re: Moving apt (and hence bootstraps) from GnuPG to Sequioa (via gpgv-sq)

On 2024-11-22, Frank Guthausen wrote: >> 1. The GnuPG upstream forked the OpenPGP standard into his own >>thing called LibrePGP, and GnuPG 2.4 implements that new thing >>and is by default incompatible with other OpenPGP implementations. > > Which kind of default incompatibility is impleme

Re: Moving apt (and hence bootstraps) from GnuPG to Sequioa (via gpgv-sq)

On 2024-11-21, Julian Andres Klode wrote: > As for ports without gpgv-sq, this does not affect them, > they can be served by the gpgv alternative. Once a gpgv-sq > is available, it's important to note that no migration happens To me it looks like we will sligthly grow the base system and have dif

Re: RFC: "Recommended bloat", and how to possibly fix it

On 2024-11-06, Colin Watson wrote: > In some ways I think what we're missing is really a way to do the > equivalent of "extras" in Python packages > (https://peps.python.org/pep-0508/#extras): effectively groups of > additional dependencies to enable some kind of feature that you can opt > into if

Re: New requirements for APT repository signing

On 2024-03-03, RL wrote: > It does - but also makes me wonder: is this going to affect Debian users > with 3rd party repositories when they upgrade to trixie? (or is that not > yet known?) In theory. I don't know if there are any statistics on 'popular' 3rdparty repositories and their keys. But a

Re: Another take on package relationship substvars

On 2024-02-23, Niels Thykier wrote: > If it was to happen, I suspect that ${shlibs:Depends} would not be the > best argument. First off, dpkg-shlibdeps has infrastructure to > selectively demote scanned elf binaries to a different substvar. > Secondly, I struggle to think of a real world case,

Re: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition

On 2024-02-01, Carsten Schoenert wrote: > What is the rationale behind rising a bug report at 9:51pm my time and > firing a *direct* NMU upload just 11min later (according to the time > stamps from the emails)? > I as the uploader for libcoap have no chance to do any action on this > bug report

Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs

On 2024-01-22, Simon McVittie wrote: > Unfortunately, perhaps because common build systems like Autotools, > Meson and CMake make it awkward to use non-numeric SONAME suffixes, With CMake it is actually quite simple. Even to a point where it is easy to get wrong: add_library(Foo SHARED foo.cpp)

Re: Policy: should libraries depend on services (daemons) that they can speak to?

On 2024-01-07, Ansgar wrote: > 1. libpulse0 & friends > -- > If the answer is "yes", this would result in an application that can > output audio via Pulseaudio or Jackd and linking the respective > liubraries pulling in *both* Pulseaudio and Jackd (and possibly other > sound s

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

On 2024-01-05, Sebastian Ramacher wrote: >> libpoppler-cpp0v5 >> libpoppler-glib8 >> libpoppler-qt5-1 >> libpoppler-qt6-3 >> libpoppler126 Poppler core (126ish) changes SONAME by release and is in general not supposed to be used by well-behaving applications. the frontentds (cpp,glib,Qt*) is sup

Re: bring a newer version of a package into stable (nsis-3.09-1 into Debian "bookworm")

On 2023-12-22, Thomas Gaugler wrote: > Hi, > > I thought a package in Debian "bookworm" could be updated via a > "bookworm proposed updates request" . > > It looks like I did not fully understand the process. Therefore I kindly > ask for assistance in updating th

Re: debian/copyright format and SPDX

On 2023-09-08, Jeremy Stanley wrote: > Since Debian's machine-readable format has been around longer than > either of the newer formats you mentioned, it seems like it would > make more sense for the tools to incorporate a parser for it rather I do think that this is another point of "we should k

Re: autodep8 test for C/C++ header

On 2023-08-07, Benjamin Drung wrote: > while working a whole week on fixing failing C/C++ header compilations > for armhf time_t [1], I noticed a common pattern: The library -dev > packages was missing one or more dependencies on another -dev package. > Over 200 -dev packages are affected. I don'

Re: 64-bit time_t transition for 32-bit archs: a proposal

On 2023-06-07, Paul Wise wrote: > On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote: > >> I've been reading the discussion around i386 a bit and found the >> direction it has taken a little unproductive. > > I note that there are a number of packages available on i386 but not > available on a

Re: Debian choice of upstream tarballs for packaging

On 2021-08-16, Paul Wise wrote: > While discussing PyPI with the Python team, it was pointed out that > sometimes the tarball contains things that cannot be regenerated from > just the VCS snapshot, such as information stored in the VCS history, > so perhaps the recommendation should be to prefer

Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

On 2020-10-27, Vagrant Cascadian wrote: > Though, of course, identifying the exact reproducibility problem would > be preferable. One of the common issues is test suites relying on the > behavior of __FILE__ returning a full path to find fixtures or other > test data. has QFIND_TESTDATA been adap

Re: reopening bugs closed by removal after package reintroduction?

On 2020-05-12, Paul Wise wrote: > On Tue, May 5, 2020 at 7:15 AM Paul Wise wrote: > >> Should we be automatically reopening these bugs? > > enrico suggested on IRC that we should be doing this. I think in general it should be decided on a case by case basis. if it was removed yesterday and reint

Re: should all bug reports be filed against /source/ packages?

On 2019-10-27, Ansgar wrote: > We have usertags and other mechanisms that allow grouping bugs in > maintainer-defined ways. This is also used by pseudo-packages where we > don't have "binaries" to group bug reports by. But that moves the "default" work, where users is right at least more than 50

Re: should all bug reports be filed against /source/ packages?

On 2019-10-23, Ansgar wrote: > So I'm wondering if we should start just filing all bug reports against > source packages? Reportbug could probably be easily changed to use > `Source: ...` instead of `Package: ...`; more places could follow later. Have you ever maintained source packages where a

Re: Git Packaging: Native source formats

On 2019-08-28, Sam Hartman wrote: > * I've heard at least one person claim that native format packages are > problematic for downstreams. > I'd like to better understand both the theoretical argument here and > to understand from downstreams whether it is an issue in practice. > > For down

Re: Preferred git branch structure when upstream moves from tarballs to git

On 2019-05-07, Ansgar wrote: > The concept behind 3.0 (quilt) is much easier to explain: extract > tarballs, optionally apply some patches provided. With the bonus that > users who have used other distributions before might already know about > most of this which lowers barrier of entry. Impleme

Re: Upcoming Qt switch to OpenGL ES on arm64

On 2018-11-24, Adrian Bunk wrote: > libqt5gui5 has > 1k rdeps I think this is a fact that many people haven't grasped. And some of those are libraries... /Sune

Re: no{thing} build profiles

On 2018-10-21, Jonas Smedegaard wrote: > I disagree that libgpgme11 should depend/recommend/suggest gnupg at all: > As a library it cannot possibly declare how tight a relationship to > declare - instead, all _consumers_ of the library must declare whether > they depend/recommend/suggest gnupg.

Re: Updating the policy for conflicting binaries names ? [was: Re: Re: New package netgen-lvs with binary /usr/bin/netgen - already taken]

On 2018-09-08, Sylvestre Ledru wrote: >> Two different packages must not install programs with different >> functionality but with the same filenames. >> > I think the policy should be changed. > It was possible to accommodate that when the archive was a few thousand > packages. > Or am

Re: Should the weboob package stay in Debian?

On 2018-07-26, Marc Dequènes wrote: > I also like the idea of a single binary with subcommands, would be > easier than remembering all the commands. > > But as I said unless upstream does agree on something, we're not going > to maintain an alternate version. Would it be sufficient small mainte

Re: Removing Qt4 in Buster

On 2017-09-22, Jonathan Dowland wrote: > On Tue, Sep 05, 2017 at 03:29:31PM -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: >>Jonathan Dowland >> qtscrob > > The right thing to do here is probably to remove this from the archive. > But out of curiosity I did look at porting it forward to q

Re: "not authorised" doing various desktoppy things

On 2017-01-03, Ian Jackson wrote: > Can someone please help explain to me how these things are supposed to > work ? Specifically, how is (presumably as a consequence of me > logging in using a display manager) my session supposed to be granted > the ability to manage various system resources like

Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages

On 2016-10-06, Leopold Palomo-Avellaneda wrote: > Then I would like to ask when we must think that we need a transition f= > or a=20 > the package. If these test shows a binary compatibility of 99%, do we n= > eed to=20 > create a need soname bump and initiate a transition?=20 Always use common s

Re: A new tool for backward compatibility analysis of API/ABI interfaces in Deb packages

On 2016-10-06, Ponomarenko Andrey wrote: > The tools are based on different software stacks. > The pkg-abidiff is based on ABI Compliance Checker and ABI Dumper tools > (https://github.com/lvc) > developed since 2009. The ABI compliance checker is the only tool that I have tried that actually w

Re: Bug#832748: ITP: greatcmakecookoff -- Usefull and less than usefull cmake recipes

On Thursday 28 July 2016 20:57:30 Ole Streicher wrote: > Hi Sune, > However, it is not just "works-for-me", since it is used in a different > place from where it was developed, so the code found its friends > (unfortunately). And it might even find more friends if available in debian. And then m

Re: Bug#832748: ITP: greatcmakecookoff -- Usefull and less than usefull cmake recipes

On Thursday 28 July 2016 15:33:55 Ole Streicher wrote: > URL : https://github.com/UCL/GreatCMakeCookOff/wiki > Description : Bunch of CMake pain in the baker > This is a repository of useful and less than useful CMake recipes. After reading it thru, I would really like to ques

Re: where to report translation bugs?

On 2016-07-15, Jonas Smedegaard wrote: > Where should I most appropriately report bugs in translations of long = > > descriptions? I think somehow the translations for the relevant language. > > Concretely the danish translation for android-platform-tools-base has = > > its command names transla

Re: OpenSSL 1.1.0

On 2016-06-27, Gert Wollny wrote: > Hello,  > > >> = Qt 4 >> >> Qt 4 is dead upstream, so we have two choices: >> >> - Someone to come up with a patch. > > I volunteer to look into this. From what I've seen in DCMTK, the > changes are not too intrusive, most of the time it is just replacing > di

Re: Debian i386 architecture now requires a 686-class processor

On 2016-05-18, Julien Cristau wrote: > Why aren't those bugs RC? Either we give both users on old hardware a bad experience or all the users on new hardware a bad experience. /Sune

Re: Packaging of static libraries

On 2016-04-11, Alastair McKinstry wrote: > What uses require PIC static libraries that cannot be satisfied by building > -static --whole-archive ? Linking a static library into a dynamic library. /Sune

Re: Opt out style recommends

On 2016-04-09, Jonas Smedegaard wrote: > I disagree that we need a new field: Simply lower to at most suggest the = > daemon: It is for the daemon to declare a stronger dependency. > Anyone needing the daemon can install the daemon - you shouldn't expect = > libraries to pull in daemons (just as y

Re: support for merged /usr in Debian

On 2016-01-05, Paul Wise wrote: > On Mon, Jan 4, 2016 at 2:14 AM, Russ Allbery wrote: > >> And yet, it works, and it means that we don't have to try to harass a >> thousand package maintainers into doing essentially untestable busy-work >> to try to move things around between /usr, /bin, and /lib

Re: Bug#800769: pbuilder: conffiles not removed

On 2015-10-12, Jakub Wilk wrote: > Because of a latent bug in debian/rules, pbuilder_0.217 shipped multiple > files that belonged to pbuilder-uml, including > /etc/pbuilder/pbuilder-uml.conf. This is bug #800416, which was promptly > fixed in pbuilder_0.218. The faulty package was only in unsta

Re: promoting virtualbox-dkms to virtualbox pre-depends

On 2015-09-22, Gianfranco Costamagna wrote: > -Pre-Depends: dpkg (>= 1.15.6~) > +Pre-Depends: dpkg (>= 1.15.6~), virtualbox-dkms (= ${source:Version}) | > virtualbox-source (= ${source:Version}) I don't see what it would fix to have virtualbox-source installed at any point help in anything. And

Re: Packaging certain libraries as "end-user software"

On 2015-07-17, Ansgar Burchardt wrote: > So, I still plan to drop the extra library packages and just move the > shared library to libdune-*-dev. I'd suggest you set it up with shlibs that ensures that packages built against these libraries aren't installable in the archive. /Sune -- To UNSUB

Re: Proposal, a Build-Depends-Optional field

On 2015-05-25, Gianfranco Costamagna wrote: > I know this might introduce some problems (binNMU?, ABI/API > incompatibilities?) It will also give 'feature-flip-flop' on the available architectures. You never know if that library is actually installable, so it would just be discarded giving poor

Re: Arch-dependent files in /usr/share

On 2014-11-02, Josselin Mouette wrote: > Le dimanche 02 novembre 2014 à 10:33 -0800, Steve Langasek a écrit : >> This is /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service, >> which is the sole location for declaring services to dbus (i.e., there is no >> corresponding path /usr/li

Re: post-jessie: header only C++ library package (static?)

On 2014-10-19, Rene Engelhard wrote: > On Sun, Oct 19, 2014 at 04:39:20PM +0200, Jerome BENOIT wrote: >> > What I know of is >> > - large parts of boost and >> > - seqan. >> >> If you are looking for samples: mpfrc++ [1] can be added. > > And mdds. And parts of libvigraimpex. > > And I am just pa

Re: post-jessie: header only C++ library package (static?)

On 2014-10-18, Osamu Aoki wrote: > Do we have some mechanism to track such situation? No automatic one if the maintainer of the 'using' package is unaware of it. If the maintainer is aware, we have the Built-Using mechanism. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian

Re: Proper notation for common licenses

On 2014-09-23, Simon McVittie wrote: > 2. Redistributions in binary form must reproduce the above copyright > notice, this list of conditions and the following disclaimer in the > documentation and/or other materials provided with the distribution. you could also just provide it in some

Re: rc bugs

On 2014-09-11, Brian May wrote: > My reading of the criteria is it depends on your interpretation of "makes > unrelated software on the system break". What does "unrelated" mean? In > this case it seems they are related as package Y depends on package X. Or > maybe it means "unrelated" as in gene

Re: systemd, again (Re: Cinnamon environment now available in testing)

On 2014-09-07, Sune Vuorela wrote: > I had my systems painfully and transparantly upgraded to systemd. And > I'm happy it happens. Please keep it this way. I apparantly like pain. or maybe s/ful/less/ is the appropriate reading. /Sune -- To UNSUBSCRIBE, email to debian

Re: systemd, again (Re: Cinnamon environment now available in testing)

On 2014-09-07, Chris Bannister wrote: > Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking > upgrades here, not new installs. I had my systems painfully and transparantly upgraded to systemd. And I'm happy it happens. Please keep it this way. I do want my systems to look the

Re: Standardizing the layout of git packaging repositories

On 2014-08-16, Raphael Hertzog wrote: > I believe that most of the current workflows do respect this rule (except > for the case where you only store the debian directory). I do think that this is quite common, and my preferred way of doing things. It is easy for newcomers to handle, easy for me

Re: Reverting to GNOME for jessie's default desktop

On 2014-08-12, Octavio Alvarez wrote: > > > On 09/08/14 04:30, Jonas Smedegaard wrote: >> Quoting envite (2014-08-09 10:43:25) >>> XFCE (does not mount my USB disks) >> >> Did you perhaps suppress recommends? > > Should this really be a Recommends? It surely fits the definition of Recommends. |

Re: systemd now appears to be only possible init system in testing

On 2014-07-23, Sune Vuorela wrote: > On 2014-07-23, Thomas Goirand wrote: > and you doesn't again say "Let's have > someone run over specific developers with a bus", then the CoC is good. Dear Thomas I sincerely apologize for the above line. Somehow my intern

Re: systemd now appears to be only possible init system in testing

On 2014-07-23, Thomas Goirand wrote: > If the CoC makes it impossible for Norbert to express himself in the way > he just did, then the CoC is bad and should be repelled. If the CoC helps ensure that Norbert doesn't again say "I don't give a shit about other people's work" - and you doesn't again

Re: say goodbye to network-manager-strongswan?

On 2014-07-16, Thomas Goirand wrote: > BTW, it feels weird that the package build-depends on debhelper when it > really is using CDBS. The debian/copyright is also quite wrong, as it If you use cdbs' debhelper module (which runs the various dh_foo commands), you need to ensure debhelper is availa

Re: Bloody noob dumb question

On 2014-07-04, Hans wrote: > I have the sourcecode of a little program (umtsmon), which has to be compiled > for libqt3. But now I want it make compilable for latest libqt. I want to > change nothing else, just make it compilable. Porting from Qt3 to Qt4 is not that simple, but you can look at

Re: How to avoid stealth installation of systemd?

On 2014-07-03, Joerg Jaspert wrote: > On 13626 March 1977, Norbert Preining wrote: >> Joerg, please be reasonable. > > I entirely am, and thats why such a hate package won't bypass me, unless > there is one of > a CTTE decision, > a GR forcing me, or > the ftp team overruling me. Thanks. /Sun

Re: How to avoid stealth installation of systemd?

On 2014-07-01, Steve Langasek wrote: > https://bugs.debian.org/src:systemd-shim > > Show me a bug report, not FUD. I'd rather point to the likely-faulty code. it is likely in or around src:kde-workspace/powerdevil/daemon/backends/upower/powerdevilupowerbackend.cpp when checking for suspend c

Re: How to avoid stealth installation of systemd?

On 2014-07-01, Steve Langasek wrote: > The question is which of these is a worse outcome for the jessie release. I > come down firmly on the side that breaking desktops on upgrade is a worse > outcome than being behind on the latest and greatest user session interface= > s. We already have broke

Re: How to avoid stealth installation of systemd?

On 2014-07-01, Carlos Alberto Lopez Perez wrote: > Maybe desktops user don't care much about the init system as long as > they can boot to the desktop. They care as long as everything works. And for "everything works" to keep on happening, we need a effective migration to systemd, or a army of de

Re: MATE 1.8 has now fully arrived in Debian

On 2014-06-27, Thorsten Glaser wrote: > But this is precisely why we're in an OSS movement here. > We can change this, and we should, so that the other > solutions do *not* die out. We should *not* accept the > might of "the others all do this"! The way is to put your time/money where your mouth

Re: edos.debian.net is back as qa.debian.org/dose

On 2014-05-23, Ralf Treinen wrote: > Which packages exactly contain these applets ? I guess in this case we > should continue providing the xml files with the data, which is quite > easy to do. At least kde-workspace has code that can provide it as sources for the weather desktop widget. (It is n

Re: edos.debian.net is back as qa.debian.org/dose

On 2014-05-23, Ralf Treinen wrote: > yes. I didn't keep this in the new version since I felt that these weather > icons are more of a gimmick than really useful. The important information > is in the numbers displayed on the summary table, and in the detailed > explanations. We have packages in s

Re: Bug#747535: systemd-fsck?

On 2014-05-12, Bas Wijnen wrote: > A default is only relevant at the time the functionality is first installed. > After that, whatever was installed should stay until the user requests to > change it (or there is a technical reason that it can no longer be installed). > In the case of an init syst

Re: systemd-fsck?

On 2014-05-09, Steve Langasek wrote: > I don't think systemd integration is in a state today that this is ready to > become the default. I don't think I have an opinion of the exact state today other than 'works for me in most cases', but I do think we are quite late in the process for making it

Re: systemd-fsck?

On 2014-05-09, Svante Signell wrote: > Well, I've not been asked if I wanted to switch to systemd based boot > when upgrading. I think this is a bug in init system choice and should > be reported. How to go back to sysvinit? I'd expect it to be a bug if I don't get migrated to systemd at some upg

Re: A question about patches for upstream

On 2014-05-03, Thorsten Glaser wrote: > This does not, of course, prevent people like the Mesa maintainers > from refusing to do it. I’ve got no idea how to enforce DevRef on > them, though. Thank you for volunteering to help forwarding bug reports for the mesa package. /Sune -- To UNSUBSCRIB

Re: About a mass bug report not based on Sid or Jessie.

On 2014-04-16, Santiago Vila wrote: > I would call that a serious design flaw. The design "flaw" as I see it is that projects built using autotools can be built on systems that hasn't got autotools installed. The way to accomplish that is to have these giant autogenerated scripts. Other build s

Re: Debian default desktop environment

On 2014-04-05, Josselin Mouette wrote: > Especially one as minor as the installation CD which has no actual > conceivable use today. At least I don't think that anything 86xish that can't boot from a usb stick is wihtin what we should target as 'default experience'. Maybe even stretching it to '

Re: Does partial upgrade between stable and testing must be supported ?

On 2014-04-05, Vincent Danjean wrote: > The maintainer think that he does not need to do anything about > that. People should just upgrade all their packages from stable to > testing when r-base-core is upgraded. > Other people (and me) disagree and think that other broken r-related > packages

Re: Debian default desktop environment

On 2014-04-03, Dmitry Smirnov wrote: > As KDE fan I do not like Gnome. Those who forget to choose DE in instal= > ler=20 Part of me wants to have KDE Plasma Desktop as the default workspace, because it is completely awesome. Other parts of me is happy that it is not the default because then we d

Bug#743250: ITP: hotpaultag -- Graphical System Activity Monitor

Package: wnpp Severity: wishlist Owner: Sune Vuorela * Package name: hotpaultag Version : snapshot Upstream Author : Paultag fanclub * URL : http://babe.debian.plumbing * License : code MIT/X11, artwork needs clarification Programming Lang: C++, QtQuick

Re: systemd patent fees - who pays?

On 2014-03-28, Sebastian Feld wrote: > Now that Redhat and Suse have been contacted by ORACLE regarding to > licensing the SMF patents a question arises for Debian: Citation needed. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Troubl

Re: jquery debate with upstream

On 2014-03-11, Paul Tagliamonte wrote: > On Tue, Mar 11, 2014 at 06:09:40PM +, Ian Jackson wrote: >> I don't think this is a significant breach of the DFSG. > > Ah, but you do acknowledge this *is* a breach, even if a small one. > > > So this comes down to where the line is, like I said. "As

Re: pulseaudio related problems....

On 2014-02-18, Lars Wirzenius wrote: > On Tue, Feb 18, 2014 at 12:09:11AM +0100, Andrew Shadura wrote: >> Is it not? It's much more convenient than fighting with a broken audio >> server which was written by a bunch of not really sane people suffering >> from some extreme form of a NIH syndrome. >

Re: Bug#727708: Fsck SystemD and its developers and its users. GR to override this please.

On 2014-02-12, Kevin Chadwick wrote: > On Wed, 12 Feb 2014 11:25:14 -0500 > Paul Tagliamonte wrote: >> >> https://lists.debian.org/debian-devel-announce/2014/02/msg5.html >> >> Can we please end this thread? > > Don't tell me it was just a vote with licensing issues being taken by > many ove

Re: virtual/alternative B-D (was Re: libtiff5 transition)

On 2013-12-06, Thorsten Glaser wrote: > Hm indeed. Makes me wonder whether it would not be better to make > libtiff-dev the real package and abandon libtiffN-dev altogether. > (Never understood why the -dev packages need the numbers, anyway.) The -dev packages needs numbers if you want to have se

Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor

On 2013-11-16, Russ Allbery wrote: > If someone proposed to remove nvi from the archive because vim is better, > I would be quite annoyed. If it ever did get removed from the archive, I > would probably adopt it and reintroduce it, because nvi is the editor that > I'm used to for small files and

Re: Bug#729660: ITP: xemacs21 -- highly customizable text editor

On 2013-11-16, John Paul Adrian Glaubitz wrote: > On 11/16/2013 11:43 AM, Mark Brown wrote: >> On Fri, Nov 15, 2013 at 09:49:49PM +, Dmitrijs Ledkovs wrote: >>=20 >>> Why should Debian carry this package? >>=20 >> It's a package that we've carried since forever and which has a >> userbase.=20

Re: systemd effectively mandatory now due to GNOME

On 2013-10-27, Brian May wrote: > * Some people say this means it needs systemd running as pid=1, same say it > doesn't. Am still confused here. The facts seems to be that logind/systemd in version 204 (the current one in debian) doesn't need systemd as pid 1, but latest upstream (version 205 and

Re: Please assume good faith (was Re: systemd effectively mandatory now due to GNOME)

On 2013-10-27, Thomas Goirand wrote: > If you don't mind that I ask: are you a GNOME developer? Olav is a gnome developer, yes. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http:/

Re: Proposal: switch default desktop to xfce

On 2013-10-25, Joey Hess wrote: > Hmm, I just gave KDE a try with my laptop fliped to tablet mode, > and did not see anything that works better than xfce. I was still stuck > fatfingered with a tiny panel, and once I started konqueror, could > not drag to scroll the page, or make any other gesture

Re: Proposal: switch default desktop to xfce

On 2013-10-25, Neil Williams wrote: > Equally, is there genuine support for tablets within Debian beyond the > problems with GUIs and touchscreens? I'm not aware of anything > approaching usable GUI support, even discounting touch. Plasma Active is quite mature and I'm sure the debian KDE team wo

Re: Proposal: switch default desktop to xfce

On 2013-10-25, Neil Williams wrote: > Other desktop environments have similar features without requiring a > change of init system. It was a choice by GNOME upstream and a choice Other desktop environments either are reimplementing bits of systemd or is having some more or less weird bugs related

Re: Proposal: switch default desktop to xfce

On 2013-10-25, Steve McIntyre wrote: > We've had this discussion multiple times over the years. I've been > told multiple times that we still have a non-negligible set of users > owning/running hardware that can't do DVDs. I'm not 100% convinced > myself of how large or critical this use case is,

Re: Proposal: switch default desktop to xfce

On 2013-10-25, Dominik George wrote: > However, I must admit that even if the standard XFCE installation does > not depend on systemd, it would be even worse if a user came along and > wanted to extend their user experience by installing some XFCE addon and > *that* would magically switch their in

Re: Proposal: switch default desktop to xfce

On 2013-10-25, Josselin Mouette wrote: > What are the reasons exactly for deliberately depriving the default > installation’s users of a more complete and featureful desktop? I've said that for years, but we still haven't changed to KDE Plasma Desktop as the default. /Sune -- To UNSUBSCRIBE

Re: libravatar in the BTS [Re: bugs.debian.org: something's wrong...]

On 2013-10-02, Don Armstrong wrote: > The avatars are now fully federated, and all caching and retrieval is Yay! > Anyone who wants to set up their own > http://wiki.libravatar.org/running_your_own/, or you can use libravatar > or gravatar if you do not wish to do so (or you can do nothing, and

Re: qmake and "make dist"

On 2013-09-25, Daniel Pocock wrote: > qmake doesn't appear to provide a "make dist" facility, at least not the > way the project is currently configured. Unless for autotools projects where you might want to store pregenerated files in the tarball, I've never seen the reason for make dist. For a

Re: Bug#709758: Replacing a binary package by another one(was: Communication issue?)

On 2013-09-04, Steve Langasek wrote: > Unless apt has gotten smarter recently (which is not out of the question), > no. It's a common misconception that apt will care about Provides/Replaces > for selecting new packages on dist-upgrade, but while it seems like a nice > idea, TTBOMK it's never bee

Re: We need a global decision about R data in binary format, and stick to it.

On 2013-08-05, Paul Tagliamonte wrote: > IMVHO, this is the same as how we should treat images (I mean, for any > data format, not just this one case of a pickled object) - if the image > was a photo, clearly the .jpg or .png or whatever we get is the best way > to communicate this data, but if th

Re: PulseAudio

On 2013-07-20, Andrei POPESCU wrote: > Have you been reading debian-user lately? One of the first=20 > recommendations is still "uninstall pulseaudio and see if it works". I have no idea on how to get sane people writing answers on debian-users. I personally run out of sanity when done with debia

Re: SONAME migration: from liblambda0 to liblambda1

On 2013-07-15, Jerome BENOIT wrote: > When the SONAME increments the associated binary library package has a new > name, > so the SONAME suffix has to increment as well accordingly: for a library > package > lambda, the binary library package could be renamed from liblambda0 to > liblambda1. >

Re: bluetooth (Re: PulseAudio

On 2013-07-17, Holger Levsen wrote: > same with bluetooth >=20 > I don't use bluetooth, I don't want the bluetooth stack installed but yet I= > do=20 > see how this is a sensible thing to install with the default desktop. Same= >=20 > with PA I'd say. especially both of them. They're needed when

  1   2   3   4   >