Re: New requirements for APT repository signing

[Sune Vuorela]

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 assuming they're doing key
rolls at 5-10 years intervals or less, it should be okay. 
Or just if the 3rdparty repository doesn't have decade(s) long history.

> (release-notes do say to remove all 3rd party packages before upgrades
> but i suspect that is ignored: helpful to provide a heads-up anyway)

But that doesn't remove the old imported keys from the keyring. Which I
guess is the main issue is a combination of things:
 - People never reinstall their system
 - Someone 10 years ago added a now insecure key to their apt and forgot about 
it.
 - Modern hardware might be able to in the not too distant future
   recreate matching keys...
Even if said repository is now dead and reoved from the keyring. If just
one of those were not valid, we could probably keep ignoring the issue. 

/Sune

Re: Another take on package relationship substvars

[Sune Vuorela]

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, where demoting 
> ${shlibs:Depends} would matter a lot. That is, a case where the right 
> answer is not just splitting these binaries into a separate package if 
> they are that consuming in dependencies.

I have seen it as real life usecases where there is a main binary that
has plugins for integrations with , and just having those
plugins work when the integration point is needed.

Usually though, they are using dpkg-shlibdeps to selectively demote
scanned elfs to a different substvar, given that the 'main binary' is
already a elf binary with some dependencies, so doing it with 'all of
them' is likely unlikely for that case.

For example:

dpkg-shlibdeps -Tdebian/dirmngr.substvars -dRecommends
debian/dirmngr/usr/lib/gnupg/dirmngr_ldap -dDepends
debian/dirmngr/usr/bin/dirmngr


http://codesearch.debian.net/search?q=-dRecommends=1

http://codesearch.debian.net/search?q=-dSuggests=1

/Sune

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

[Sune Vuorela]

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! This behavior I'm not expecting within Debian.
> What are the plans now with forwarding the underlying issue to upstream?
> Upstream is very responsive and I've good contacts to the upstream 
> authors, but who is doing this work now?

I'm mostly a bystander here. But there is no underlying issue to forward
to upstream. Ex. The debian toolchain has been changed on most 32bit
architectures to produce different code if time-related types are
involved.

This involves doing a giant library transition involving a 4 digit
number of source packages, and it will while the transition is ongoing,
be a *nightmare* of crashes for anyone with a machine on one of the
involved 32bit architectures, so it need to happen in a very short
timeframe.

We should just be happy that there is at least 4 people working in
shifts around the clock trying to get this done in less than a week of
calendar time.

/Sune

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

[Sune Vuorela]

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)
set_target_properties(Foo PROPERTIES VERSION 1vorlon.0.0 SOVERSION
1smcv)

$ objdump -x libFoo.so | grep SONAME
  SONAME   libFoo.so.1smcv

ls:

libFoo.so -> libFoo.so.1smcv
libFoo.so.1smcv -> libFoo.so.1vorlon.0.0
libFoo.so.1vorlon.0.0

/Sune

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

[Sune Vuorela]

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 servers as well).

I'm a bit .. it depends. But it might end up being delegated to the
applications to do it manually maybe.

Assuming an audio providing program (netradio streamer or something)
that just does pulseaudio. No backends. no configuration. Just pulse.

I would not expect users to figure out that a Suggests: pulseaudio was
the missing bit needed to get the application to actually work.

On the other hand

> 3. The general case
> ---

I'm currently investigating an upstream bug report from a sister
distribution.

A document reader links thru various intermediate steps to libspeech2, a
library from src:speech-dispatcher to talk to speech-dispatcher daemon
to do text-to-speech. And libspeech2 (at least thru the intermediates)
ends up not giving me an easy failure to act upon.

How do the distribution maintainer of the document reader ensure that 
the users know that they need speech-dispatcher around for that to work?


Maybe the question is also a bit .. "it depends". 
Assuming 10 different sound servers, one might be the one we as a
distribution considers the default. Maybe the default one should have
libfoo: Recommends: foo.
and the non-defaults should have
libbar: Suggests: bar

So that users actually likely get a system that works?

I guess it is a tradeoff between extra-cruft-on-systems and
likely-that-systems-work, and we need to draw a line somewhere.

I might also be slightly biased towards adding slightly extra cruft on
systems to ensure they work because of the package collection I'm
involved in (KDE and friends) as opposed to people maintaining packages
mostly used by server administrators, maybe even container-heavy server
administrators.

/Sune

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

[Sune Vuorela]

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 supposedly stable.

But I can confirm that all of them uses time-related types in their
api's. (time_t specifically)

For added fun, the cpp frontend does it like this on all architectures:
typedef unsigned int /* time_t */ time_type;

in deprecated api, replaced with time_t in non-deprecated methods. That
might require extra investigations.

(The commit deprecating and replacing api specifically mentions y2k38)

/Sune

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

[Sune Vuorela]

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 the nsis-3.08-3 package in Debian 
> "bookworm" to nsis-3.09-1.

Unless you are special, only targetted fixes are normally allowed in
stable.

You should be able to do a full diff between the nsis 3.08-3 and 3.09-1
and explain all of the changes and why it is a targetted minimal fix.
(Except maybe version number changes)

If there is unrelated changes, consider looking at a targetted fix and
try to get a 3.08-4 in testing instead.

Once you have a tested nsis where you have read and understand and can
explain the full diff of what you want to do, please attach the full
diff to said bug report and remove the moreinfo tag.

>From your description, the two fixes sounds worth fixing in stable.

/Sune

Re: debian/copyright format and SPDX

[Sune Vuorela]

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 kill our babies if
they don't take off". And preferably faster if/when "we lost" the race.

We carried around the debian menu for a decade or so after we failed to
gain traction and people centered on desktop files.

We failed to gain traction on the structure of the copyright file, and
spdx is the one who has won here.

This is just going to be more useless work. Things can more or less the
same, so let's go with the one where we get the least work requirements
in the long run, and not put more resources into the current version.

/Sune

Re: autodep8 test for C/C++ header

[Sune Vuorela]

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't think this is a important problem that some headers might have
special conditions for use. I'd rather have our developers spend time
fixing other issues than satisfying this script.

Is it a problem that Qt -dev packages also ships windows, mac or android
specific addons headers? I don't think so. Rather the opposite. When
doing cross platform work, it is nice that grepping across the includes,
I also see some of the platformspecific functions in separate files.

Is it a problem that a header file is also shipped that provides
integration with other-big-thing but 99% of developres/downstream users
don't care about and no Depends is in place? I don't think that's a
problem. I'd rather have the header available for the 1% than having to
create an extra -dev package just for that.

Debian development resources is a finite resource, so let's not waste
it.

/Sune

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

[Sune Vuorela]

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 amd64, is anyone planning on an MBF about this issue?

I got curious. Some of them are hurd specific. Others are a i386
specific version, either for fewer processor capabilities or just a
specific one, like sigend bootloader packages and such. Lets remove
those and see what we have left. 

oh. and a few are miscategorized. And some binary-only non-free.

Some byte code interpreter for games and games. Apparantly puts pointers
in ints.
>  fenix deb devel optional 
> arch=arm,armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,mipsn32,mipsn32el,powerpc,s390,sh4,sparc
>  fenix-plugin-mpeg deb devel optional 
> arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
>  fenix-plugins deb devel optional 
> arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
>  fenix-plugins-system deb devel optional 
> arch=arm,armel,armhf,hppa,i386,kfreebsd-i386,hurd-i386,m68k,mips,mipsel,sh4,powerpc,s390,sparc
>  pixbros deb games optional 
> arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4
>  pixfrogger deb games optional 
> arch=armel,armhf,hppa,hurd-i386,i386,kfreebsd-i386,m68k,mips,mipsel,powerpc,sh4

Last upstream release uploaded in 2004. Unsure why restricted
>  fnfx-client deb utils optional arch=i386
>  fnfxd deb utils optional arch=i386

TV card grabber. Last upstream release uploaded in 2002. Unsure why
restricted
>  gatos deb misc extra arch=i386
>  libgatos-dev deb libdevel extra arch=i386
>  libgatos0 deb libs extra arch=i386

Tv card configuration. Last upstream uploadde in 2002. Unsure why
restricted
>  atitvout deb misc optional arch=i386,ia64

loads vst plugins. But others does that on 64bit as well
>  lmms-vst-server deb sound optional arch=i386

Hardware driver helper. The accompanying dkms package seems to also be
x86_86
>  sl-modem-daemon deb non-free/misc optional arch=i386

playstation2 emulator. Requires sse2.
>  pcsx2 deb games optional arch=i386

snes emulator. last upstream release 2007
>  zsnes deb otherosfs optional arch=any-i386


Old soundblaster card related:
>  adlibtracker2 deb sound optional arch=i386
>  sb16ctrl-bochs deb otherosfs optional arch=any-i386

m68k helper. Unsure why restricted
>  mac-fdisk-cross deb otherosfs optional arch=i386,m68k
>  pmac-fdisk-cross deb otherosfs optional arch=i386,m68k

lisp runtie. unsure why restricted
>  cmucl deb lisp optional arch=i386
>  cmucl-clm deb lisp optional arch=i386

game stuff, mostly contrib, likely binary data for binary blobs
>  steam deb contrib/oldlibs optional arch=i386
>  steam-libs-i386 deb metapackages optional arch=i386
>  etqw deb contrib/games optional arch=i386
>  etqw-server deb contrib/games optional arch=i386
>  quake4 deb contrib/games optional arch=i386
>  quake4-server deb contrib/games optional arch=i386
>  steamcmd deb non-free/games optional arch=i386

Non-free or non-free binary dependencies
>  intel-mkl-linktool deb non-free/utils optional arch=i386
>  libmkl-gf deb non-free/libs optional arch=i386
>  libmkl-intel deb non-free/libs optional arch=i386
>  libmkl-p4 deb non-free/libs optional arch=i386
>  libmkl-p4m deb non-free/libs optional arch=i386
>  libmkl-p4m3 deb non-free/libs optional arch=i386
>  libmkl-vml-ia deb non-free/libs optional arch=i386
>  libmkl-vml-p4 deb non-free/libs optional arch=i386
>  libmkl-vml-p4m deb non-free/libs optional arch=i386
>  libmkl-vml-p4m2 deb non-free/libs optional arch=i386
>  libmkl-vml-p4m3 deb non-free/libs optional arch=i386
>  speech-dispatcher-ibmtts deb contrib/sound optional arch=i386

i386-version of something and helpers and hardware enablement:
>  fp-units-i386 deb devel optional arch=i386
>  fp-units-i386-3.2.2 deb devel optional arch=i386
>  fwupd-i386-signed-template deb admin optional arch=i386
>  fwupd-i386-signed deb admin optional arch=i386
>  libnvidia-legacy-340xx-cuda1-i386 deb non-free/libs optional arch=i386
>  nvidia-legacy-340xx-driver-libs-i386 deb non-free/libs optional arch=i386
>  libnvidia-legacy-390xx-cuda1-i386 deb non-free/libs optional arch=i386
>  nvidia-legacy-390xx-driver-libs-i386 deb non-free/libs optional arch=i386
>  nvidia-legacy-390xx-driver-libs-nonglvnd-i386 deb non-free/libs optional 
> arch=i386
>  grub-efi-ia32-signed deb admin optional arch=i386
>  grub-efi-ia32-signed-template deb admin optional arch=i386
>  grub-efi-ia32-signed-template deb admin optional arch=i386
>  sse2-support deb misc optional arch=any-i386
>  shim-helpers-i386-signed-template deb admin optional arch=i386
>  shim-helpers-i386-signed deb admin optional arch=i386
>  strace64 deb utils optional arch=i386,powerpc,s390,sparc
>  wine32 deb 

Re: Debian choice of upstream tarballs for packaging

[Sune Vuorela]

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 the VCS but always
> compare the VCS with upstream tarballs and packaging ecosystem tarballs
> using diffoscope in order to discover differences important to Debian.

At least some upstreams I'm involved in is having translations managed
different from source code, and only pulled into the tarball at tarball
generation time (though it might be committed to the git tag)

Though this is not part of the "packaigng ecosystems", we should ensure
that recommendations aren't too specific.

/Sune

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

[Sune Vuorela]

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 adapted to work with this, or are we just
"lucky" that most packages don't actually build and run test suites?

I don't think that we should make it harder for maintainers to enable
test suites on their packages, when we can just record the filepath in
the build info and still have things reproducible.

/Sune

Re: reopening bugs closed by removal after package reintroduction?

[Sune Vuorela]

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 reintroduced with almost same version
today, then probably yes.

If it was a 0.0.git-2005-01-20 removed in 2010 and version 2.0
reintroduced today, probably not.

But I guess it also depends on if it is one bug that needs work, or a
"Thanks for your contribution to Debian by maintainig this package. Now
also walk thru these 1000 old crap that probably is irellevant
today"-experience

/Sune

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

[Sune Vuorela]

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% of the time, to pure developer work. 

/Sune

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

[Sune Vuorela]

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 source produced many
different binaries?

I'm not sure the libreoffice maintainer, nor bug reporters, would
appreciate this.

Back when all the kdepim packages (mail, nntp, rss, calendar, contacts,
...) were one source, I'm sure dealing with them would have been a
nightmare.

/Sune

Re: Git Packaging: Native source formats

[Sune Vuorela]

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 downstreams where it is a problem, are you using a git or a
>   non-git workflow?

I've recently (professionally) been involved with a .. sidestream?.
Where going into debian packages, rpm packages and others to fetch their
fixes (as separate files) into a different environment (yocto).

Having the ability to extract separate patches - with clear
documentation - was so much simpler than trying to extract it from
anywhere else.


/Sune

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

[Sune Vuorela]

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.  Implementation details
> like constructing a .dsc are indeed messy.

I currently work with some yocto guys trying to get some of their
recipes adapted to better multilib support. I've been pointing to
debian/rules and debian/patches/* as places to find inspiration for
"weird things". The fact that the packages in question have been in 3.0
(quilt) with either a only-debian repository or full upstream source
have been very easy to glance over.

So from an external-ish PoV, current state of things is very nice. 

But of course, it is not our primary customers. But probably our
secondary ones.

/Sune

Re: Upcoming Qt switch to OpenGL ES on arm64

[Sune Vuorela]

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

[Sune Vuorela]

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.

libgpgme is completely useless without gnupg. I think it is perfectly
fine for these kind of relations, unless we really are in corner-case
territory. See for example fam.

/Sune

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

[Sune Vuorela]

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 I missing a key reason for this?

If we allow conflicts in this case, we disallow users to use both tools
at the same time.

And on multiple-users machines, it is kind of a random what tool they
actually get when they invoke a binary.

I think that is a disservice to our users.

Suddenly getting a sudo clone invoked when you want your build to build
fast is kind of .. suprising.

/Sune

Re: Should the weboob package stay in Debian?

[Sune Vuorela]

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 maintenance and still acceptable for
everyone if we did

 - install the current binaries into /usr/lib/woob
 - create a /usr/bin/woob command with subcommands
 - create a mappings file /usr/lib/woob/mappings
 - create a tool to help find unmapped tools and update the mappings
   file

The woob command would then lookup the "original" name in the mappings
file and exec the correct one with remaining args.

This is probably fairly low maintenance once created, but it still has
the bad names on the file system, though hidden away out of path.

the user interface would then be 

| woob recipe 

/Sune

Re: Removing Qt4 in Buster

[Sune Vuorela]

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 qt5: I found
> someone else's patch for the code, then got as far as wondering why

Unless it does things interacting directly with the windowing system or
uses the qt3 support part of qt4, it is probably in the "99% of code
just works"

> there wasn't a libqt5-dev available to my Debian machines before I ran
> out of time.

you most likely don't want a libqt5-all-the-things-dev. Qt nowadays is
so large and has so many components that you probably aren't using all
of it.

Start from qtbase5-dev and add on from there.

/Sune

Re: "not authorised" doing various desktoppy things

[Sune Vuorela]

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 the power and
> network settings.

>
> I'd love to know where to start debugging, or where to send bug
> reports.

The rough way things work is that network-manager asks policykit if
ijackson is allowed to do . If I recall correctly, for most
networky (and removable media things), the default policykit
configuration is that 'local logged in users' are allowed to do this.
logind is asked if ijackson is logged in as a local user or as a remote
user. And the message trickles back the same way.
There is also somewhere iirc a configuration bit to require a password
on the way.

> Presumably there is also a way to override things and permanently
> grant my account the relevant privilege.  That would be fine for
> single-user computers (including most laptops). 

That would probably be some policykit configuration file you can do this

> But I want to fix
> this in the general case.  I suspect that (for example) desktoppy
> removeable media, or audio access, may be affected (although I don't
> use those things).

I like your attitude of fixing the general case, and I do have the same
suspicion as you.

I do think mbiebl's debugging start point is good.

/Sune

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

[Sune Vuorela]

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 sense. Always investigate.

But if there is a 'red' item in the abi report, likely.

/Sune

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

[Sune Vuorela]

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 works and doesn't provide any false OK's or false Not-ok's of
what I have noticed so far.

(The only "false not-ok" I've seen, which is also questionable, and only
tagged at medium level is of enums of the construction
enum Modes {
  firstmode = 0,
  secondmode = 1,
  thirdmode,
  fourthmode,
  NumberOfModes
}

where the last one gets renumbered when a fifthmode is added, and only
to be used in loops as end point. But in general it is a style I don't
recommend, and it is also one incredibly hard to autodetect)

/Sune

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

[Sune Vuorela]

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 more users. and then all the bugs starts to show up, some likely 
requires api changes to fix. Then a lot of build failures and ...

> If I can't remove it, I in principle have two choices here: either I
> include it in each package; this would however violate the policy §4.13.
> Or I package it separately, then I am close to the "must not be so buggy
> that we refuse to support them" requirement in §2.2.1.

I do think that code duplication and keeping it private would be preferred in 
this case over packaging it separately.

Which parts is actually used ?

And the ones that are used to download an internet as part of the build needs 
to be fixed/changed/replaced anyways.


 
> If you (or someone else) could volunteer to help me in removing this
> dependency, I would be glad, and would withdraw the ITP.

I'm at least not volunteering to help to do anything with non-public sources.


/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

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

[Sune Vuorela]

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 question the inclusion into the 
archive. 

It seems like undertested, fragile works-for-me-and-probably-no-one-else cmake 
code.

There is a couple of find modules that might be interesting, but I would 
really suggest to get those upstreamed into either cmake or extra-cmake-
modules and the rest of the hacks should preferably not be used.

I took a look at sopt and purify upstreams, and couldn't find that they used 
cmake at all?

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Re: where to report translation bugs?

[Sune Vuorela]

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 translated which renders the long description pretty =
>
> useless.

In this case, try find Joe Dalton

/Sune

Re: OpenSSL 1.1.0

[Sune Vuorela]

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
> direct access to member variables with access functions because the
> structures are now opaque.  

I would suggest talking to upstream, getting something working with qt5,
then backporting that patch.

/Sune

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

[Sune Vuorela]

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

[Sune Vuorela]

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

[Sune Vuorela]

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 you shouldn't expect documentation =
> to pull in binaries).

Sometimes, the daemon is an implementation detail of the library. Or a
hard requirement for the library to function. Sometimes it is even a
hard requirement for the library to not crash.

/Sune

Re: support for merged /usr in Debian

[Sune Vuorela]

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 to support a
>> tiny handful of systems for which other approaches are available.
>
> The bin-or-sbin-binary-requires-usr-lib-library tag in adequate tests this.
> piuparts runs adequate for every single package in Debian.

Does it also catch when for example a udev configuration file wants to
run an executable living under /usr ?

/Sune

Re: Bug#800769: pbuilder: conffiles not removed

[Sune Vuorela]

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 unstable for 
> about a day.

I'd say "tough luck" to both the people in unstable who will have an
obsolete configuration file that they need to fix up by hand.

/Sune

Accepted kdevelop 4:4.7.1-2 (source) into unstable

[Sune Vuorela]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 26 Sep 2015 08:41:23 +0200
Source: kdevelop
Binary: kdevelop kdevelop-data kdevelop-dev kdevelop-dbg kdevelop-l10n
Architecture: source
Version: 4:4.7.1-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers <debian-qt-...@lists.debian.org>
Changed-By: Sune Vuorela <s...@debian.org>
Description:
 kdevelop   - integrated development environment for KDE
 kdevelop-data - data files for the KDevelop IDE
 kdevelop-dbg - debugging symbols for KDevelop
 kdevelop-dev - development files for the KDevelop IDE
 kdevelop-l10n - localization files for the KDevelop IDE
Changes:
 kdevelop (4:4.7.1-2) unstable; urgency=medium
 .
   * Add libkdevcompilerprovider to ensure that code navigation works.
   * Backport patch from upstream to fix a crash when parsing bits/c++config.h.
Checksums-Sha1:
 7cf34cdcc1cf5da9a5b7a76f16eaab961d9c4fb2 2437 kdevelop_4.7.1-2.dsc
 7eb5800af84784a4785829052a8727c8c6746d1f 24204 kdevelop_4.7.1-2.debian.tar.xz
Checksums-Sha256:
 674e32c2799f76aee21f028a3284df3fd0bf33dc2aa76bb74dcfb8f5ecf5e6f5 2437 
kdevelop_4.7.1-2.dsc
 af220c2509d7d783f06b51eb98e26aca8eabca60cdddc4b45152b8ea7a0ca218 24204 
kdevelop_4.7.1-2.debian.tar.xz
Files:
 1cca0113ec7da8c3f20df41755d2451e 2437 devel optional kdevelop_4.7.1-2.dsc
 c6e0ef0ce7c054223dc632ec80084c8b 24204 devel optional 
kdevelop_4.7.1-2.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWBm/5AAoJEBowdl3x8NPtcdwP/2dzX+hoZTKTwmsHYMi0xnuE
LLoQ7u+mw8Mtu/DBi45Qm46dtncMgNmlSJ7j5MAQgftLMke6AXjq6Mhy7YvkCHk4
HRT7VmgV/4G4tpaUtcX0rSAxdjrMmy+8+KALHjjvkGNnLEBjwo2qrNn/gpaiI+Go
hXuOeeDccQbV8hkWG29LqEhb1qLYJGAScsMzzIHXbez2ThAGtIEHF0f3gfkdzbd5
tEgGRMHnG8GPEc1Ly92GUPp0rc+orQLsQnLts9nrJ2oCgZ5mS9/ZrX9uIkVCjNoA
hDNSe2FTONpUTL0nZdfZDoshY1+p0t6+Nc8KHPUNMmYSoaBvwlS/5sS0kFPOeymF
2F2JDNzA3dNvE3nWZTym/BARuDpAT766BWNXKBYcVlKcOwOUEaDOp7f30moA1ME0
qDtqIV5vDwHUscVy1lrp6SuEgr5kVAiAvOND8D0pAnUXTjLgRHKRmK/585+n9y3O
7kWxgmDHFCbOlf8WeRmWXSd0fcG3nGPfjjPkaQWq99VvxHKFG8VTCgB64/RpPSuH
P4pbpOV3+kFbxl0jsCeNttbWEsz9XuCoqxZbGRv+UoqXH12BJhK63r+YYauYUjFN
Zsn2hYij3rw/Q6pFdVfGTSOjC/3IMI5w6aecrAiszdMHlCLEa1d2DO7NnrKjOBt1
aWWDZ4T0xyumVvJ6R+MG
=A+gv
-END PGP SIGNATURE-

Re: promoting virtualbox-dkms to virtualbox pre-depends

[Sune Vuorela]

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 note that one can run kernels that doesn't do dkms.

/Sune

Re: Packaging certain libraries as end-user software

[Sune Vuorela]

On 2015-07-17, Ansgar Burchardt ans...@debian.org 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 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/mobhsl$lvt$1...@ger.gmane.org

Re: Proposal, a Build-Depends-Optional field

[Sune Vuorela]

On 2015-05-25, Gianfranco Costamagna costamagnagianfra...@yahoo.it 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 user experience.

I really think this is a bad idea.

/Sune


-- 
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/mjum99$8v7$1...@ger.gmane.org

Re: Arch-dependent files in /usr/share

[Sune Vuorela]

On 2014-11-02, Josselin Mouette j...@debian.org 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/lib/dbus-1/system-services).  The file varies by
 architecture because it encodes a reference to the binary daemon, which is
 shipped in a multiarch path.

 The same holds for gconf-service and gconf-defaults-service. The path to
 the binary is a MultiArch one, but the package is MA: foreign precisely
 for this reason. 

And for various .desktop files


All the cmake files in the list, on the other hand, should be shippable
in /usr/lib/

I'm not sure about all the lintian overrides in there. Maybe a fix needs
to be applied in lintian for arch specific overrides ?

/Sune


-- 
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/m36663$5uc$1...@ger.gmane.org

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

[Sune Vuorela]

On 2014-10-19, Rene Engelhard r...@debian.org 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 packaging rapidjson...

Eigen.

/Sune


-- 
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/m217sg$nte$1...@ger.gmane.org

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

[Sune Vuorela]

On 2014-10-18, Osamu Aoki os...@debian.org 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.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m1u5rs$l2b$1...@ger.gmane.org

Re: Proper notation for common licenses

[Sune Vuorela]

On 2014-09-23, Simon McVittie s...@debian.org 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 other materials provided, like,
for example the source package or the manual.

/Sune


-- 
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/lvrmum$9us$1...@ger.gmane.org

Accepted kdevplatform 1.7.0-1 (source amd64 all) into experimental, experimental

[Sune Vuorela]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 19 Sep 2014 23:42:58 +0200
Source: kdevplatform
Binary: kdevplatform8-libs kdevplatform-dev kdevplatform-dbg libsublime8 
libsublime-dev kdevplatform-l10n
Architecture: source amd64 all
Version: 1.7.0-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org
Changed-By: Sune Vuorela s...@debian.org
Description:
 kdevplatform-dbg - debugging symbols for the KDevelop platform
 kdevplatform-dev - development files for the KDevelop platform
 kdevplatform-l10n - language package for the KDevelop platform
 kdevplatform8-libs - shared libraries for the KDevelop platform
 libsublime-dev - development files for the sublime user interface library
 libsublime8 - User interface library
Changes:
 kdevplatform (1.7.0-1) experimental; urgency=medium
 .
   * New upstream release.
 .
   [ Andreas Cord-Landwehr ]
   * Rename packages due to soname bump:
 - kdevplatform7-libs - kdevplatform8-libs
 - libsublime7 - libsublime8
   * Update install files.
   * Update copyright.
 .
   [ Pino Toscano ]
   * Update copyright.
   * Update install files.
   * Bump the debhelper compatibility to 9:
 - bump compat to 9
 - bump the debhelper build dependency to 9
   * Convert rules to the dh sequencer with kde addon.
   * Remove unused cdbs build dependency.
 .
   [ Sune Vuorela ]
   * Switch a script to /bin/bash - it uses bash specific features.
Checksums-Sha1:
 293654fee6e3f493cbc345fccae9104faf231c77 1939 kdevplatform_1.7.0-1.dsc
 9fc196e7cb09ab33fd5cfbf5af19aa7c513efdc9 1900040 kdevplatform_1.7.0.orig.tar.xz
 09e2ff10ff29ae7cd2ccdf7ffe472c9a2a7abd4b 16524 
kdevplatform_1.7.0-1.debian.tar.xz
 691b049f41f4025a8811088b5f679e539679 2431962 
kdevplatform8-libs_1.7.0-1_amd64.deb
 92697a707cd54e02f3bd0874ffc2677e35c9568d 282772 
kdevplatform-dev_1.7.0-1_amd64.deb
 1cd9c86c8443f9703d17928703e5dabe86fe5be3 47350560 
kdevplatform-dbg_1.7.0-1_amd64.deb
 6d31f34aa59c0f85e1439be674c2b5567a958fa7 102268 libsublime8_1.7.0-1_amd64.deb
 7dfe0f9ef0843bece0fc7c532a1e46061ec378ae 26902 libsublime-dev_1.7.0-1_amd64.deb
 720ee03f96e39f66c8b9490ec58d37c6d5e42dbf 668492 
kdevplatform-l10n_1.7.0-1_all.deb
Checksums-Sha256:
 d442e6d427f0a77f341095f8bda0aed7c0b477ef54a009b095400f0db23caab6 1939 
kdevplatform_1.7.0-1.dsc
 bfd765019511c5c9abc19bc412c75d7abd468f1a077ce4bc471cd6704b9f53f7 1900040 
kdevplatform_1.7.0.orig.tar.xz
 d20d95c1c9e203ff6594cf3c2f4a0511ace6caedec799d217b5abbe9a9148737 16524 
kdevplatform_1.7.0-1.debian.tar.xz
 f6aae553c01acce7786a9ad607933dbfb7f5fc7f1e7fde8d92367415f3c58906 2431962 
kdevplatform8-libs_1.7.0-1_amd64.deb
 a5617e7953fa24c4e970adb673244a03cec6f8da15cea2ce8ba5a4edbfbebd37 282772 
kdevplatform-dev_1.7.0-1_amd64.deb
 409f04858964de460241d8ce75f296d6516727948be008bbb3a3973d83090cf1 47350560 
kdevplatform-dbg_1.7.0-1_amd64.deb
 f370573b5200772b2e8383596f4672bec8b5f15e8f6efd56dad9ded26f57e3b1 102268 
libsublime8_1.7.0-1_amd64.deb
 cfab041613251c663cee13f4f61185d9dc802c8b2b14051d7405fe13e22cfec4 26902 
libsublime-dev_1.7.0-1_amd64.deb
 e2457ce80fe6ac22c84ff40c19f95352772da25d7cbc1c3f8f47abcd6df04220 668492 
kdevplatform-l10n_1.7.0-1_all.deb
Files:
 5e3fab6aae6e8b4b254066c07c037051 2431962 libs optional 
kdevplatform8-libs_1.7.0-1_amd64.deb
 20358089772e048a0b796a49f62476f9 282772 libdevel optional 
kdevplatform-dev_1.7.0-1_amd64.deb
 3496a5be0018e5a0c733b14c405c76f3 47350560 debug extra 
kdevplatform-dbg_1.7.0-1_amd64.deb
 69fd856da27d028a91b5fc773a6b3010 102268 libs optional 
libsublime8_1.7.0-1_amd64.deb
 98a857a087312b3ae4f63b3a0bf14e75 26902 libdevel optional 
libsublime-dev_1.7.0-1_amd64.deb
 2c938433a2726704a8ff9903e4cb7180 668492 localization optional 
kdevplatform-l10n_1.7.0-1_all.deb
 a738612eaa8d59eb4486040f60d63aa8 1939 libs optional kdevplatform_1.7.0-1.dsc
 72375e077f97b44056c76c7f85ce49ad 1900040 libs optional 
kdevplatform_1.7.0.orig.tar.xz
 bb3a0a47944ffe543049877b9c2e793f 16524 libs optional 
kdevplatform_1.7.0-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlQcpnUACgkQnMvaFgH6i0rUkACfY7nk2dMGkm6uvTLv9eHbOWd+
M88AnjSmeYdjkBiY8RHbaVdNx4Y1gSLH
=C93W
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xw3ds-00039h...@franck.debian.org

Re: rc bugs

[Sune Vuorela]

On 2014-09-11, Brian May br...@microcomaustralia.com.au 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 generated from different source packages?

Unrelated means unrelated. Stuff that has a depends or recommends
relation is not unrelated.

Imaginge upgrading your snake game implementation and your editor stops
functioning. *that's* unrelated. (Yes. this luckily happens quite rare)

/Sune


-- 
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/lv0sj7$ebt$1...@ger.gmane.org

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

[Sune Vuorela]

On 2014-09-07, Chris Bannister cbannis...@slingshot.co.nz 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 same, no matter if it is my workstation
installed-as-woody or my laptop reinstalled yesterday.

/Sune


-- 
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/luhiqv$8t6$1...@ger.gmane.org

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

[Sune Vuorela]

On 2014-09-07, Sune Vuorela nos...@vuorela.dk 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-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/luhkds$qpi$1...@ger.gmane.org

Accepted qapt 2.2.0-1 (source amd64) into experimental, experimental

[Sune Vuorela]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Wed, 03 Sep 2014 14:19:55 +0200
Source: qapt
Binary: libqapt2 libqapt-dev libqapt2-runtime qapt-utils qapt-batch 
qapt-deb-installer plasma-runner-installer kde-thumbnailer-deb 
gstreamer1.0-qapt qapt-dbg
Architecture: source amd64
Version: 2.2.0-1
Distribution: experimental
Urgency: low
Maintainer: Debian KDE Extras Team pkg-kde-ext...@lists.alioth.debian.org
Changed-By: Sune Vuorela s...@debian.org
Description:
 gstreamer1.0-qapt - GStreamer plugin to install codecs using QApt
 kde-thumbnailer-deb - KDE plugin to show thumbnails of Debian package files
 libqapt-dev - Development headers for the QApt library
 libqapt2   - QApt library package
 libqapt2-runtime - Runtime components for the QApt library
 plasma-runner-installer - KRunner plugin for installing packages
 qapt-batch - Batch package manager for KDE
 qapt-dbg   - QApt debugging symbols
 qapt-deb-installer - tool for installing deb files
 qapt-utils - complete collection of QApt package management utilities
Changes:
 qapt (2.2.0-1) experimental; urgency=low
 .
   [ Sune Vuorela ]
   * Add me to uploaders
   * Remove Jose Manuel Santamaria Lema from uploaders.
   * Remove the unused DMUA-field.
 .
   [ Floris-Andrei Stoica-Marcu ]
   * New Upstream Release
   * Updated package structure, now it is unmerged
   * Bumped up version of libqapt-runtime
   * Added new symbol file for qapt-dbg
   * Disabled tests that broke build
   * Updated dependencies
Checksums-Sha1:
 919d781a3f78c219e8efd69af545941b42e7c922 2063 qapt_2.2.0-1.dsc
 ea88d671c987f5ca331d0d55b56f6b89ef98751d 235700 qapt_2.2.0.orig.tar.xz
 6bf6b81bc014971f64088bb5dd49d8d6093e36be 8364 qapt_2.2.0-1.debian.tar.xz
 56b335c111043545b94dc3b4eabb8aaac77762e1 142486 libqapt2_2.2.0-1_amd64.deb
 d670fb41c7d963188f1b88367622c51c2557ca19 37478 libqapt-dev_2.2.0-1_amd64.deb
 7c0df43449ffe28b58e27dfe37a38eb69172bc65 59024 
libqapt2-runtime_2.2.0-1_amd64.deb
 98c9a0ab8a51ecb0fa48ca4be52ff7fb444b15e3 14568 qapt-utils_2.2.0-1_amd64.deb
 1befbfb414599c06b93d1f137fca8156a5733988 79760 qapt-batch_2.2.0-1_amd64.deb
 1d335e37a22b0fa228f84ba5616f1dfcf14de15c 70030 
qapt-deb-installer_2.2.0-1_amd64.deb
 f3f51be29240ae5626336fecee19bf307e5c706f 31794 
plasma-runner-installer_2.2.0-1_amd64.deb
 9f1177f7d3f05572918e220b4dba240115bb2642 19714 
kde-thumbnailer-deb_2.2.0-1_amd64.deb
 797948edaef0e68d3276da4b0ddc416cd08b7bfe 86192 
gstreamer1.0-qapt_2.2.0-1_amd64.deb
 4e1eaeae61abb801db178c99107c00603b372e43 4161722 qapt-dbg_2.2.0-1_amd64.deb
Checksums-Sha256:
 86e1872f8c54b06f02661773eb44e94574ebd3ffbec47a2b68ee17dc0f8cf7ce 2063 
qapt_2.2.0-1.dsc
 8f50d79f9093894fc6b00f1ee6937e547b2f00d22edde53a4990978d1d66a13c 235700 
qapt_2.2.0.orig.tar.xz
 aa9a39af73db7f96c688d4e0127df2b697b7d12ee91e06df02ed1ea0f819e988 8364 
qapt_2.2.0-1.debian.tar.xz
 5767bc018d28d214207d502e3771290aa9378d4f01c538e82ca65eb7a4723b07 142486 
libqapt2_2.2.0-1_amd64.deb
 94d182aa4fd67f09045a72f5d6e3bec9b195841859a231cc10e2b34c0ce57a9a 37478 
libqapt-dev_2.2.0-1_amd64.deb
 6aa2dccc68f5eb49ea6481fcf1a5039260e9239b239fe4c29f0e3bdc0acf08df 59024 
libqapt2-runtime_2.2.0-1_amd64.deb
 7f8183304fadfda2bd69b071a0369cf12ce5448d95fa39600b6d4c045d76c52e 14568 
qapt-utils_2.2.0-1_amd64.deb
 8b727a196c5d132aa72b27a20fd837fe68582f5d15b3121d51a9a5dfdff6d4f7 79760 
qapt-batch_2.2.0-1_amd64.deb
 357e59b49828b6e611b81b269b5f34d3a800377893e1275700f9cfe6a97f8311 70030 
qapt-deb-installer_2.2.0-1_amd64.deb
 3eb6bed773bacb286c479bbdfd71461bee53ea48a622518e6e5524c9dd452ef4 31794 
plasma-runner-installer_2.2.0-1_amd64.deb
 a971f87489daaec1ee46e6b5d79f20d3f176842e217e658248b1574da9093a70 19714 
kde-thumbnailer-deb_2.2.0-1_amd64.deb
 807ef8225375b4d780444aad1f388d97f24b8e58efa2f456b16a9d63c043d42b 86192 
gstreamer1.0-qapt_2.2.0-1_amd64.deb
 7b40b0c41fb25fe42b5ec566e2854412d9284f0800dbce4991a07f831297695a 4161722 
qapt-dbg_2.2.0-1_amd64.deb
Files:
 341d516c0d03c5f8b4cb3b68c684ddb6 142486 kde optional libqapt2_2.2.0-1_amd64.deb
 5826936b82f74f3fbf45dbf9ef0cc62d 37478 libdevel optional 
libqapt-dev_2.2.0-1_amd64.deb
 686aecbaec9afb87d4696ec0046df292 59024 kde optional 
libqapt2-runtime_2.2.0-1_amd64.deb
 e64dc481e4ed300f3413c09f6dd5338b 14568 kde optional 
qapt-utils_2.2.0-1_amd64.deb
 0fc2ecf00e2abeabb3c7ee7b480c25d4 79760 kde optional 
qapt-batch_2.2.0-1_amd64.deb
 2eded290d08f29381c63d8c4532be301 70030 kde optional 
qapt-deb-installer_2.2.0-1_amd64.deb
 9b06455ab4be4d0d54b8689dfa7d5fe7 31794 kde optional 
plasma-runner-installer_2.2.0-1_amd64.deb
 d3f7d4b3cb21134b323434585246e610 19714 kde optional 
kde-thumbnailer-deb_2.2.0-1_amd64.deb
 bbe84a5eabe74d427b9e8f0c823d6d3f 86192 kde optional 
gstreamer1.0-qapt_2.2.0-1_amd64.deb
 659b70127710e9020be27ac0d64a9977 4161722 debug extra qapt-dbg_2.2.0-1_amd64.deb
 9a9837ace817f31380512454e6d2e1bb 2063 kde optional qapt_2.2.0-1.dsc
 3bf406d1d2b39aae8bc00558610c839d 235700 kde optional qapt_2.2.0.orig.tar.xz
 eb9d633cb16a7b74a6f53a983597cb89 8364 kde optional qapt_2.2.0-1

Re: Standardizing the layout of git packaging repositories

[Sune Vuorela]

On 2014-08-16, Raphael Hertzog hert...@debian.org 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 to handle, no
need to learn a lot of git specific tools or helpers, you can mostly
ignore git if you want to.

I've a couple of times tried to get myself to actually learn various of
these newfangled tools like git-buildpackaeg and such, and each time I
end up feeling they get much more in my way that they actually help me.

So, if I can, I try my bestest to stick with a debian-only git
repository for the debian packaging. It just works. and is simple.

/Sune


-- 
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/lsr1g3$bd0$1...@ger.gmane.org

Re: Reverting to GNOME for jessie's default desktop

[Sune Vuorela]

On 2014-08-12, Octavio Alvarez alvar...@alvarezp.ods.org 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.

| The Recommends field should list packages that would be found together
| with this one in all but unusual installations.

/Sune


-- 
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/lsf8mk$10i$1...@ger.gmane.org

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

[Sune Vuorela]

On 2014-07-23, Thomas Goirand z...@debian.org 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 say Let's have
someone run over specific developers with a bus, then the CoC is good.

/Sune


-- 
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/lqnr8r$oeu$1...@ger.gmane.org

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

[Sune Vuorela]

On 2014-07-23, Sune Vuorela nos...@vuorela.dk wrote:
 On 2014-07-23, Thomas Goirand z...@debian.org 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 internal memory
mixed up one T... G... with another. 

I'm really sorry.

/Sune


-- 
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/lqnsh9$oeu$2...@ger.gmane.org

Re: say goodbye to network-manager-strongswan?

[Sune Vuorela]

On 2014-07-16, Thomas Goirand z...@debian.org 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 available.

/Sune


-- 
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/lq67p4$rk0$1...@ger.gmane.org

Re: How to avoid stealth installation of systemd?

[Sune Vuorela]

On 2014-07-03, Joerg Jaspert jo...@debian.org 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.

/Sune


-- 
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/lp5k44$4o5$1...@ger.gmane.org

Re: Bloody noob dumb question

[Sune Vuorela]

On 2014-07-04, Hans hans.ullr...@loop.de 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
http://qt-project.org/doc/qt-4.8/porting4.html
and 
http://qt-project.org/doc/qt-4.8/porting4-designer.html

I'd suggest you to also once ported to Qt4 to also look into doing the
Qt5 port.


 If you find my question stupid, it is ok, but I know nobody whom I can ask. 
 So 
 I asked the list.

the qt-interest list on the qtproject might be a better place to start.
or #qt on freenode

/Sune


-- 
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/lp5u1o$i9g$1...@ger.gmane.org

Re: How to avoid stealth installation of systemd?

[Sune Vuorela]

On 2014-07-01, Carlos Alberto Lopez Perez clo...@igalia.com 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 developers to ensure everything keeps working. I still fail to see
that army.
(for example, with the newest upower and !systemd, the kde plasma
desktop won't allow you to reboot/suspend/... the system. Having someone
investigating it would be nice)

 But I think that many sysadmins that are going to upgrade their servers
 from wheezy to jessie care about this. I bet that not few of them would
 want to stick with sysvinit for jessie at least.

The server sysadmins who cares about this reads release notes.

Please. Let's keep it working for everyone. Systemd now.

/Sune


-- 
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/loustd$fi8$1...@ger.gmane.org

Re: How to avoid stealth installation of systemd?

[Sune Vuorela]

On 2014-07-01, Steve Langasek vor...@debian.org 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 broken desktops-on-upgrade with current systemd-shim in
the archive. And it is even broken after reboot.
It might be bugs in the desktop related packages, but it is also a very
low priority one.

Also, post-upgrade-pre-reboot systems has had issues since forever, and
I think even the upgrade notes recommends to not dist-upgrade from
within X.

So, where do we want to put our resources?
Improving the actual experience once fully upgraded and rebooted? Or
ensure a better experience when in the middle of the upgrade and not yet
rebooted?

I know where I would put the resources I can allocate.

/Sune


-- 
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/lov38o$2ah$1...@ger.gmane.org

Re: How to avoid stealth installation of systemd?

[Sune Vuorela]

On 2014-07-01, Steve Langasek vor...@debian.org 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 capabilities with upower from experimental. 

Something in there doesn't properly detect that systemd-shim + logind actually 
can 
let you suspend the machine (and upower 0.99 has delegated it to
logind).

 Also, post-upgrade-pre-reboot systems has had issues since forever,

 No.  There have been very few instances in which the system was left in an
 unusable state after a dist-upgrade, even for desktops.

Try do a update of your kde-plasma-desktop across where the internal
on-disk data cache changes (at least every y in x.y.z, and sometimes in
.z releases). The web browser stops working, the email application stops
working, anything that uses the on-disk caches for looking up their
plugins ceases to work.

This is how it has been as long as I've been around.


 and I think even the upgrade notes recommends to not dist-upgrade from
 within X.

 This was written at a time when X itself was considered flaky enough that it
 posed a risk to the user's ability to complete the upgrade.  After years of

|4.1.5. Prepare a safe environment for the upgrade
|
|The distribution upgrade should be done either locally from a textmode
|virtual console (or a directly connected serial terminal), or remotely
|via an ssh link.

 Unless we bring one back by letting systemd + desktop environments screw us
 over anew.

Here is nothing new.

/Sune


-- 
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/lov93v$c79$1...@ger.gmane.org

Re: MATE 1.8 has now fully arrived in Debian

[Sune Vuorela]

On 2014-06-27, Thorsten Glaser t...@debian.org 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 is and provide the
code. Asking others to do all the work is not the way forward in OSS.

/Sune


-- 
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/lojcqb$trp$1...@ger.gmane.org

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

[Sune Vuorela]

On 2014-05-23, Ralf Treinen trei...@free.fr 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 not a debian addition, it lives in kde upstream)

I think at least at one point in time, also others had this feature.

/S


-- 
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/llpk16$f6v$1...@ger.gmane.org

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

[Sune Vuorela]

On 2014-05-23, Ralf Treinen trei...@free.fr 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 stable and unstable that uses the weather
information for providin 'debian weather' for various desktops systems.

Are we breaking them on purpose as well ?

/Sune


-- 
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/llmvhi$vqa$1...@ger.gmane.org

Re: Bug#747535: systemd-fsck?

[Sune Vuorela]

On 2014-05-12, Bas Wijnen wij...@debian.org 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 system, installation happens in d-i.

I'd be dissapointed if we don't migrate the vast majority of the users
to the default init system.

I think my support-burden will be lot smaller if all 'non-power-users'
systems are approximately the same.

/Sune


-- 
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/lkqm56$dt7$1...@ger.gmane.org

Re: systemd-fsck?

[Sune Vuorela]

On 2014-05-09, Steve Langasek vor...@debian.org 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 default. We only have half a year to iron out all
the quirks  -  including the quirks needed for a automatic upgrade from
sysvinit to systemd.

/Sune


-- 
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/lkkfp2$vc1$1...@ger.gmane.org

Re: systemd-fsck?

[Sune Vuorela]

On 2014-05-09, Svante Signell svante.sign...@gmail.com 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
upgrade.

 ii  systemd-sysv  204-10

 Which ones can I safely remove when going back to sysvinit?

That one should bring you back to sysvinit.

/Sune


-- 
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/lkidpm$hrj$1...@ger.gmane.org

Re: A question about patches for upstream

[Sune Vuorela]

On 2014-05-03, Thorsten Glaser t...@mirbsd.de 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 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/lk3ggi$lgd$1...@ger.gmane.org

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

[Sune Vuorela]

On 2014-04-16, Santiago Vila sanv...@unex.es 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 systems, like the one I know best, cmake, is needed on all
build systems in order to build packages.

It is one of the major design differences.

A simple way of fixing that design flaw is to just consider the .am /
.ac files as the sources to build from and run the relevant autotools
first, then configure, make, make install.

I don't see how you can get both the 'doesn't need autotools to build
the actual software' and 'updates everything on build' at the same time.

/Sune


-- 
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/limk1l$1jj$1...@ger.gmane.org

Re: Debian default desktop environment

[Sune Vuorela]

On 2014-04-05, Josselin Mouette j...@debian.org 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 'anything consumerlike that has a cdrom
drive' is not within the range of 'default experience'

/Sune


-- 
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/li087v$6hu$1...@ger.gmane.org

Accepted arora 0.11.0+qt5+git2014-04-06-1 (source amd64)

[Sune Vuorela]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sun, 06 Apr 2014 20:18:52 +0200
Source: arora
Binary: arora
Architecture: source amd64
Version: 0.11.0+qt5+git2014-04-06-1
Distribution: unstable
Urgency: low
Maintainer: Sune Vuorela s...@debian.org
Changed-By: Sune Vuorela s...@debian.org
Description: 
 arora  - simple cross platform web browser
Changes: 
 arora (0.11.0+qt5+git2014-04-06-1) unstable; urgency=low
 .
   * New upstream snapshot. Updated to svuorela-qt5 branch hash
 0.11.0-31-g37dc64f. It includes various qt5 related regressions
 with Q_WS_X11 not being defined.
   * Add build-arch and build-indep targets.
   * Bump standards versions
Checksums-Sha1: 
 2cd1c16b54047352e1b5d9a85c3d12b826f927e3 1207 
arora_0.11.0+qt5+git2014-04-06-1.dsc
 bd59591084099c555e93ac533bd71c9a3e9b366f 677620 
arora_0.11.0+qt5+git2014-04-06.orig.tar.xz
 443905c6f60d155f23722689a72852402927869c 5808 
arora_0.11.0+qt5+git2014-04-06-1.debian.tar.xz
 1ef9f7ffa432900613097d94b8c22199d3c902f9 790472 
arora_0.11.0+qt5+git2014-04-06-1_amd64.deb
Checksums-Sha256: 
 297dd8978c2a775dbc385ace1eba2e4546b300c1304c7b5cbd401874ce8c2153 1207 
arora_0.11.0+qt5+git2014-04-06-1.dsc
 260f35aa0fe30cef14298076970dedc47a56f4477c23c85c8bc4351040bb87aa 677620 
arora_0.11.0+qt5+git2014-04-06.orig.tar.xz
 9f6fc1332fd2b9afef96a6a7714658ed2d03dc7ddc93bfda36783a6b68d4f9f7 5808 
arora_0.11.0+qt5+git2014-04-06-1.debian.tar.xz
 c77d1f2a164c13a770c39de78a20a968ed3b148f44851daa38be6c01abce0cb4 790472 
arora_0.11.0+qt5+git2014-04-06-1_amd64.deb
Files: 
 761badb06e1e94c9bbc87cf70b34caac 1207 web extra 
arora_0.11.0+qt5+git2014-04-06-1.dsc
 8e9955c33e6635086797714641e45fbb 677620 web extra 
arora_0.11.0+qt5+git2014-04-06.orig.tar.xz
 eaddb1e59bec40dd0ed8a71216650995 5808 web extra 
arora_0.11.0+qt5+git2014-04-06-1.debian.tar.xz
 6555768609785f3a5fd28039d453e408 790472 web extra 
arora_0.11.0+qt5+git2014-04-06-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlNBntQACgkQnMvaFgH6i0rCkQCdErSGuC+EBzTgMGWvl8dSopZY
4QYAmQG0flJsdlMQPJoczkMWfiCR9RzK
=nwuw
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1wws7j-00045w...@franck.debian.org

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

[Sune Vuorela]

On 2014-04-05, Vincent Danjean vdanjean...@free.fr 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 must be either removed or upgraded automatically by apt
 when r-base-core is upgraded (due to additional conflicts/breaks/...
 declarations)

I agree with you and other people. partial upgrade should work.
Requiring packages to be uninstalled is a great way of ensuring that
partial upgrades works.

/Sune


-- 
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/lhpm81$eti$1...@ger.gmane.org

Accepted arora 0.11.0+qt5+git2014-04-05-1 (source amd64)

[Sune Vuorela]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Sat, 05 Apr 2014 20:59:22 +0200
Source: arora
Binary: arora
Architecture: source amd64
Version: 0.11.0+qt5+git2014-04-05-1
Distribution: unstable
Urgency: low
Maintainer: Sune Vuorela s...@debian.org
Changed-By: Sune Vuorela s...@debian.org
Description: 
 arora  - simple cross platform web browser
Closes: 668808 736196 739229
Changes: 
 arora (0.11.0+qt5+git2014-04-05-1) unstable; urgency=low
 .
   * New upstream snapshot
 - including jturcotte's Qt5 patchset to give a newer qtwebkit.
 - including a patch by me to limit the used ssl ciphers.
   Closes: #739229
 - Fixes the start page's xml. Closes: #668808
 - Fixes crash in bookmarknode dtor. Closes: #736196
   * Refresh patch.
   * Low urgency because switching to Qt5 is not a small thing.
Checksums-Sha1: 
 10f14a79ea7136f171bb71183be4b340bc23693c 1207 
arora_0.11.0+qt5+git2014-04-05-1.dsc
 5ea0e5c73a19238d03e53171490a0f51c3d7ed9e 677756 
arora_0.11.0+qt5+git2014-04-05.orig.tar.xz
 127162d0a3f43dcea95345c6a6c837d82e0c0612 4068 
arora_0.11.0+qt5+git2014-04-05-1.debian.tar.xz
 0ea85258d8158613f8ab00c9428600273092c359 785914 
arora_0.11.0+qt5+git2014-04-05-1_amd64.deb
Checksums-Sha256: 
 923d75d37ca3a5e0407c6baf13fa7f5e7f7a6609d2c2ee32b80a0c515de14dc9 1207 
arora_0.11.0+qt5+git2014-04-05-1.dsc
 19d2cae7c203e4fa3332819b62f6b26b83e15d3354abc948fd8881e9bdfdfaae 677756 
arora_0.11.0+qt5+git2014-04-05.orig.tar.xz
 09b813018246cc9a5907e42c9d361bdaf53847d2857c46f00edb7b31c099 4068 
arora_0.11.0+qt5+git2014-04-05-1.debian.tar.xz
 3a9bfc37e95f4fcd649f96f984f74ed0e90b880365cfd05ae65364def4d70903 785914 
arora_0.11.0+qt5+git2014-04-05-1_amd64.deb
Files: 
 cbc882fdfd0e27dee93360939bef0c78 1207 web extra 
arora_0.11.0+qt5+git2014-04-05-1.dsc
 260c311ea20de0dac7eddec02ad1fda4 677756 web extra 
arora_0.11.0+qt5+git2014-04-05.orig.tar.xz
 6647d94b58bf6f0d63e87740878bfabb 4068 web extra 
arora_0.11.0+qt5+git2014-04-05-1.debian.tar.xz
 d15b7da045f6292f78ee2f1880e9f866 785914 web extra 
arora_0.11.0+qt5+git2014-04-05-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlNAaNwACgkQnMvaFgH6i0r2zgCdHGIb4UIg//uAM9ZJdtNyAIzY
zqEAoIyp73wfvp+MEbjbG9OQp0BISsOl
=Bw9y
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1wwye4-lw...@franck.debian.org

Re: Debian default desktop environment

[Sune Vuorela]

On 2014-04-03, Dmitry Smirnov only...@debian.org 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
don't have all sorts of weird wishes about oh noes. networkmanager or
Please use this non-integrated piece of messaging software because it
does something that no one uses.

/Sune


-- 
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/lhmi0f$b12$1...@ger.gmane.org

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

[Sune Vuorela]

Package: wnpp
Severity: wishlist
Owner: Sune Vuorela s...@debian.org

* 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
  Description : Graphical System Activity Monitor

small graphical utility which display the system activity in a
very special way. 
.
Shows various images of his majTAGsty that get hotter and hotter while
your cpu gets hotter.
.
Of course, if you can be shocked by hotness, don't use it!


The package will be maintained by the Paultag fanclub.
There is still a need to fully solve licensing around the artwork.

To test yourself, install cmake, qtbase5-dev, qtdeclarative5-dev and
qtdeclarative5-qtquick2-plugin


-- 
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/20140331220106.10226.38978.reportbug@dabney.localhost

Re: systemd patent fees - who pays?

[Sune Vuorela]

On 2014-03-28, Sebastian Feld sebastian.n.f...@gmail.com 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. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lh3pjj$96b$1...@ger.gmane.org

Re: jquery debate with upstream

[Sune Vuorela]

On 2014-03-11, Paul Tagliamonte paul...@debian.org 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 a Debian Developer, I will uphold the DFSG except where it is
inconvenient  ?

I actually think the DFSG is a great document and we shouldn't just
stray from it because it is inconvenient.

If I had to disregard the DFSG in some cases, I'd rather see rfc files
in our files than sourceless javascripts.

/Sune


-- 
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/lfnufq$f0n$1...@ger.gmane.org

Re: pulseaudio related problems....

[Sune Vuorela]

On 2014-02-18, Lars Wirzenius l...@liw.fi 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.

 I think that attacking people isn't a good way to make one's point, or
 to foster a constructive discussion. It also makes me, and probably
 other people, feel uninterested in participating in any discussions on
 this and other Debian mailing lists.

I agree.

/Sune


-- 
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/ldvaa6$6ju$1...@ger.gmane.org

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

[Sune Vuorela]

On 2014-02-12, Kevin Chadwick ma1l1i...@yahoo.co.uk 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 over real issues as some sites seem to be saying. Do voters give
 their primary reasons?


The link above does have a 'see link for discussion'.
People have said why they have voted what they voted.

Technical reasons seems to have been the primary driver behind it,
though a bit 'how healthy does the project seem to be' has also been
involved.

Licensing was mentioned, but I don't have the impression that it was
neither primary nor secondary concerns.

/Sune


-- 
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/ldgidf$bub$1...@ger.gmane.org

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

[Sune Vuorela]

On 2013-12-06, Thorsten Glaser t...@debian.org 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 several around at
the same time.


Having the unversioned -dev package be a virtual package worksr fine as
long as 
1) no one will need a versioned dependency on the unversioned virtual
dev package
2) only one package is providing the virtual package at a time.

Yes. 2) is theoretically racy. but from a practical purpose, the race is
irrelevant.

/Sune


-- 
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/slrnla3oc2.j8.nos...@sshway.ssh.pusling.com

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

[Sune Vuorela]

On 2013-11-16, Russ Allbery r...@debian.org 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 for root editing tasks, I want to keep
 using it, and none of the things that are wrong with it are fatal for that
 usage.

Note that nvi is orphaned, no removal could happen given that many
people thinks vim is better.

/Sune
 - this post written using vim


-- 
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/slrnl8hc0g.j8.nos...@sshway.ssh.pusling.com

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

[Sune Vuorela]

On 2013-11-16, John Paul Adrian Glaubitz glaub...@physik.fu-berlin.de 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

 That's not really an argument. We've also had uae and e-uae

I'm kind of wondering why we are arguing how someone who has
maintained zlib longer than the rest of us have been DDs combined
should spend his time.

Mark has a great and long track record in debian and apparantly needs
xemacs21 to do proper work, why should we put obstacles in the way for
that?

/Sune


-- 
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/slrnl8erf5.j8.nos...@sshway.ssh.pusling.com

Re: systemd effectively mandatory now due to GNOME

[Sune Vuorela]

On 2013-10-27, Brian May br...@microcomaustralia.com.au 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 newer) does.

 * Some people say that the parts of systemd that Gnome uses should be split
 into a separate package, so, in theory, it should be possible to install
 just those parts without installing all of systemd. However the systemd
 object to doing this (I missed the reasons behind this).

It is more work for the systemd maintainers, and all people will gain is
a couple of kilobytes of free diskspace from the systemd executable
(haven't looked up its size)

 * Gnome is said to work fine even on platforms that don't have systemd
 installed. Does this mean that systemd is optional?

It is more a matter of defining 'fine'. Apparantly suspend/hibernate is
bound now logind, as well as user switching and a couple of other
features

 * For reasons I don't properly understand, some people seem to think a
 decision is needed to make or not make systemd the default in Debian.

It is more a matter of many people wanting a new init system because
features and others seems to not want something new because they know
what they have.
And since we can't have two init systems being the default, and we can't
expect maintainers of packages to actively test a bunch of different
init systems, we need a decision to be able to move forward.

 Have I missed anything or got anything wrong?

You missed a few bits, but yeah.

/Sune


-- 
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/slrnl6s465.j8.nos...@sshway.ssh.pusling.com

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

[Sune Vuorela]

On 2013-10-27, Thomas Goirand z...@debian.org 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://lists.debian.org/slrnl6q96e.j8.nos...@sshway.ssh.pusling.com

Re: Proposal: switch default desktop to xfce

[Sune Vuorela]

On 2013-10-25, Josselin Mouette j...@debian.org 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.

/troll

/Sune


-- 
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/slrnl6kms1.j8.nos...@sshway.ssh.pusling.com

Re: Proposal: switch default desktop to xfce

[Sune Vuorela]

On 2013-10-25, Dominik George n...@naturalnet.de 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 init system.

apparantly no one is actually reading what has been written earlier, so
let me try write it in larger letters:

 
   m   ##  
 mmmm mmmmm   mm#mm   mmm #  #mmmm mm
   ##  #  #   #   ##  #  ##  #  # #
   ##   #   m#m##  #  ##   #  #   #
 mm#mm  #   #  mmmmm  mm#mmmm  mm#mm  #   #  #m#
 m  #
   
 
m  # 
  mmm   m   m   mmm   mm#mm   mmm   m   mmm# mmmmmm  
 # m m  #   ##  #  # # #  # # # # #  #   
  m   #m#m##  # # #  #   # #   #  m#  # 
 mmm   #mmmmm  #mm  # # #  #m## ##m#  mm#  #mm 
 m  #   
  
 
 #  #
 #   m   mmm   mmm   mmm#   mmmmmmmmm  m mm  
 # m  #  # #  #  # # #  # #  #  #  ##  # 
 ##m#  #   #  # #   #  #   #  #   m #   # 
 #  m  mm#  #m#  #mm #m##  #m#  #mm  mmm #   # 
m  # 
   
 
  m m   #  
  mmm   mm#mm  mmm  m m mmmmm#mm   mmm   # mm  mmm   
 # ##   #m m m   #  ###  #   #   
 #   ##m  #m#m##  ##  #   #   #   
 #m#mm mmm   # #   mm#mmmm  #mm  #   # mm#mm 
 
 
 
m  m
 m mm   mmmmm#mm  mmm   m   m   mmm   mm#mm   mmm   m   mmm  
 #  ##  #   # m m  #   ##  #  # # #  #
 #   ##  #m   #m#m##  # # #   m 
 #   #  mm#mmmm mmm   #mmmmm  #mm  # # #  mmm 
 m  
   


/Sune


-- 
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/slrnl6knoe.j8.nos...@sshway.ssh.pusling.com

Re: Proposal: switch default desktop to xfce

[Sune Vuorela]

On 2013-10-25, Steve McIntyre st...@einval.com 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, but that's the
 information I have. We *could* just drop all the CD sets and be done
 with it, just keeping the netinst CD and the DVDs. Is that what people
 really want?

I think it is fine to keep the CD's as long as you want to do them, but
I don't see that it is that important to ensure that there is something
special about CD 1 and trying to squeeze stuff on to it by cutting
features.

/Sune


-- 
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/slrnl6kpn8.j8.nos...@sshway.ssh.pusling.com

Re: Proposal: switch default desktop to xfce

[Sune Vuorela]

On 2013-10-25, Neil Williams codeh...@debian.org 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 to some of the issues
the systemd suite is solving.

We still have anything in debian that ensures XDG_RUNTIME_DIR is set,
except the systemd+logind combination. This results in user session
daemons either trampling on each other or predictable shared filenames
or various other hackish things.

We have in KDE ktimezoned that is one of those 'gazillion daemons' that
all apps spawn and we frequently get bug reports about.
systemd+timezoned is also solving the same issue.

systemd+hostnamed is also solving issues. and it can probably save quite
some lines of code in kded.

very much of what e.g. kded does is plugging holes in the linux platform
on a quite high level.

Why not consolidate on shared code rather than having several bits
providing the similar functionality for fairly simple tasks ?

/Sune


-- 
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/slrnl6lapn.j8.nos...@sshway.ssh.pusling.com

Re: Proposal: switch default desktop to xfce

[Sune Vuorela]

On 2013-10-25, Neil Williams codeh...@debian.org 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 would
love to assist people wanting to get Plasma Active in in a well
supported way.

/Sune


-- 
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/slrnl6lhif.j8.nos...@sshway.ssh.pusling.com

Re: Proposal: switch default desktop to xfce

[Sune Vuorela]

On 2013-10-25, Joey Hess jo...@debian.org 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 gestures.

Plasma Active is a different user interface on top of things, not yet
packaged for Debian.

The underlying libs are shared with the rest of the workspace, so it is
just getting the last bits integrated and tested. But the debian kde
team is lacking manpower to also take that up. It is just ~3-4 source
packages and maybe enabling e.g. the okular tablet port in the okular
package.

The Plasma Active upstream people are maintaining a Mer based reference
image for a couple of tablets.

/Sune


-- 
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/slrnl6ljqd.j8.nos...@sshway.ssh.pusling.com

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

[Sune Vuorela]

On 2013-10-02, Don Armstrong d...@debian.org 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 no
 image will be displayed for you.)

Next up I guess is finding a way to have DSA setting up something to
host avatars for @debian.org addresses. hint hint :)

/Sune


-- 
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/slrnl4no1k.j8.nos...@sshway.ssh.pusling.com

Re: qmake and make dist

[Sune Vuorela]

On 2013-09-25, Daniel Pocock dan...@pocock.com.au 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 all my qmake and cmake based projects, neither that has a make dist,
I've asked my VCS for a tarball of the tag and blessed that one as 'the
release'.

/Sune


-- 
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/slrnl46d15.j8.nos...@sshway.ssh.pusling.com

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

[Sune Vuorela]

On 2013-09-04, Steve Langasek vor...@debian.org 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 been implemented.

Over in RPM land, I think they have a Obsoletes relation for a 'you
should consider this package a successor to other package'

I have missed such a thing from time to time.

/Sune


-- 
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/slrnl2f0p4.hsi.nos...@sshway.ssh.pusling.com

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

[Sune Vuorela]

On 2013-08-05, Paul Tagliamonte paul...@debian.org 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 the image was generated off an .svg,
 it should be distributed with it (and even rebuilt at build-time).

Whattabout svg files that are converted into png's and then manually
adjusted?

/Sune


-- 
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/slrnkvvdku.j0.nos...@sshway.ssh.pusling.com

Re: PulseAudio

[Sune Vuorela]

On 2013-07-20, Andrei POPESCU andreimpope...@gmail.com 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
debian-devel.

/Sune


-- 
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/slrnkuoi1b.j0.nos...@sshway.ssh.pusling.com

Re: bluetooth (Re: PulseAudio

[Sune Vuorela]

On 2013-07-17, Holger Levsen hol...@layer-acht.org 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 you want to use a bluetooth
headset in an easy way.

/Sune
 - who also likes being able to adjust the volume of different
   applications


-- 
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/slrnkuctt5.j0.nos...@sshway.ssh.pusling.com

Re: SONAME migration: from liblambda0 to liblambda1

[Sune Vuorela]

On 2013-07-15, Jerome BENOIT g62993...@rezozer.net 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.
 I thought that I could manage all of the change, but it appeared a last issue 
 that
 I have just noticed by installing the new package: the former binary package
 liblambda0 is not discarded by the new binary package liblambda1, neither in 
 Sid
 nor at the upgrading stage with aptitude.
 I guess that something is missing in `debian/control', any clue ?

At this stage, everything is working as expected. There sholudn't be any
reason to force removal of liblambda0.

What should happen here is that everything using liblambda should be
rebuild by the build daemons against liblambda1. Then when a package is
rebuilt, it will be have a newer version and be upgraded on teh users
systems.

Once all users of liblambda have been rebuilt and upgraded, the users
systems's autoremove functionality will suggest to remove liblambda0 as
it isn't used any more.


Note that the rebuilds can happen by the debian build infrastructure
without much human intervention, and the release team are helpful with
that. (it is called binNMU).

Due to how debian testing works with migrations and such, SONAME changes
(transition) must be coordinated with the release team. You can see 
https://wiki.debian.org/Teams/ReleaseTeam/Transitions for details about
that.

Hope this helps

/Sune
 - comaintainer of a couple of smallish libraries.


-- 
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/slrnkud073.j0.nos...@sshway.ssh.pusling.com

Accepted kdevplatform 1.5.1-1 (source all amd64)

[Sune Vuorela]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 28 Jun 2013 09:22:12 +0200
Source: kdevplatform
Binary: kdevplatform7-libs kdevplatform-dev kdevplatform-dbg libsublime7 
libsublime-dev kdevplatform-l10n
Architecture: source all amd64
Version: 1.5.1-1
Distribution: experimental
Urgency: low
Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org
Changed-By: Sune Vuorela s...@debian.org
Description: 
 kdevplatform-dbg - debugging symbols for the KDevelop platform
 kdevplatform-dev - development files for the KDevelop platform
 kdevplatform-l10n - language package for the KDevelop platform
 kdevplatform7-libs - shared libraries for the KDevelop platform
 libsublime-dev - development files for the sublime user interface library
 libsublime7 - User interface library
Changes: 
 kdevplatform (1.5.1-1) experimental; urgency=low
 .
   [ Andreas Cord-Landwehr ]
   * New upstream release
   * Rename packages due to soname bump:
 - kdevplatform5-libs - kdevplatform7-libs
 - libsublime5 - libsublime7
   * Add build dependency to libgrantlee-dev (= 0.1.7)
   * Raise kdelibs5-dev build-dependency (=4:4.7.0)
   * Bump Standards-Version to 3.9.4: no changes needed.
   * Update copyright.
   * Disable compilation of SVN plugin due to license
 incompatability: patches/excludeSvnPluginFromCompilation.diff
   * Remove libsvn-dev build dependency: only needed for SVN plugin.
Checksums-Sha1: 
 1c5fb5a128d6f469c688ef3748c136f2a5d84454 1905 kdevplatform_1.5.1-1.dsc
 af3e78b55c4aec97e271bc06c59186cdf77fe3d1 2272743 
kdevplatform_1.5.1.orig.tar.bz2
 f0ea52b833247b6a75e79cd7f873ce110358a1c6 22194 
kdevplatform_1.5.1-1.debian.tar.gz
 29ff87b14990768902dd4cc76208281731288574 1647514 
kdevplatform-l10n_1.5.1-1_all.deb
 bf2c9774617568984c5230a73068cf606af4fd3c 3257006 
kdevplatform7-libs_1.5.1-1_amd64.deb
 ae52e446d54a35cdff11a0fbd7ad0baa9208bc00 395284 
kdevplatform-dev_1.5.1-1_amd64.deb
 2fd71df16b5b8894067d51ded5824a4c795099cb 41772070 
kdevplatform-dbg_1.5.1-1_amd64.deb
 0db630c4f7fb63b1d8532c69770e74aa9ce72bf9 133708 libsublime7_1.5.1-1_amd64.deb
 c9f8eaac2bf273eb7a6f6d60ce0c6d19b3643ae3 34686 libsublime-dev_1.5.1-1_amd64.deb
Checksums-Sha256: 
 99ff36ea8e38cd513172433f586b5a51ac4cfd718bf7a2d9cf623feb1396e00a 1905 
kdevplatform_1.5.1-1.dsc
 37bc8985ca855673dce085722ae3cfd3703b9155eb5d0b31e60b975c976a410f 2272743 
kdevplatform_1.5.1.orig.tar.bz2
 55002384dec134119c22dec7bf4516a78474dd90989be03d1afe523204fd66f4 22194 
kdevplatform_1.5.1-1.debian.tar.gz
 da21d68e39d097c249d5dee77173e396e4ad1c833f1c07599bcfecb5cd42012a 1647514 
kdevplatform-l10n_1.5.1-1_all.deb
 53f20d37f6e7ff89113f5e07092734ee3ce4c6c4fc7d71931e403fb4ad353124 3257006 
kdevplatform7-libs_1.5.1-1_amd64.deb
 f496685d513368ef22a0bbfb1628835655f2ac269cf38b312c1db894d5759859 395284 
kdevplatform-dev_1.5.1-1_amd64.deb
 356106cc6a808b8e106dc84dce9c4f1e80769968c4410b164115db9931286107 41772070 
kdevplatform-dbg_1.5.1-1_amd64.deb
 b53f07e2dc4a973205d9d0dc3a0083fd4a017fbb67984d3f47c5342f85a12e78 133708 
libsublime7_1.5.1-1_amd64.deb
 8c385f80a258265c0079b425866b2d971e7c30118fe60199257b8048378d980c 34686 
libsublime-dev_1.5.1-1_amd64.deb
Files: 
 3b131f2d4428c8ec46842fbef86eebbe 1905 libs optional kdevplatform_1.5.1-1.dsc
 639a2cbacce0156cd0c61bed74b383c2 2272743 libs optional 
kdevplatform_1.5.1.orig.tar.bz2
 1133e04765a4752bfde2e366115e1517 22194 libs optional 
kdevplatform_1.5.1-1.debian.tar.gz
 033dd17b218018bf1db6c3c9f2b3cc05 1647514 localization optional 
kdevplatform-l10n_1.5.1-1_all.deb
 15d902e702fcb4cf3e8b373540259a07 3257006 libs optional 
kdevplatform7-libs_1.5.1-1_amd64.deb
 a1d90d156ad3749241ae50b9868fb8c7 395284 libdevel optional 
kdevplatform-dev_1.5.1-1_amd64.deb
 ddfb7fcd1a7f052cc2e7440b97f7e54a 41772070 debug extra 
kdevplatform-dbg_1.5.1-1_amd64.deb
 383b447a768ab7b680816527d35ae089 133708 libs optional 
libsublime7_1.5.1-1_amd64.deb
 84c74eca39b3b782306827539b669bb0 34686 libdevel optional 
libsublime-dev_1.5.1-1_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlHNTpoACgkQnMvaFgH6i0ophgCgq/ZRklkiiMDnha8XMbJWEtoK
xO8An1JtiLUqUV6mzRY+qCEHGG+y23Ua
=VsHN
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uyrwh-0006og...@franck.debian.org

Re: adequate now reports incompatible-licenses - need help to verify and file bugs

[Sune Vuorela]

On 2013-07-10, Andreas Beckmann a...@debian.org wrote:
   osgearth: incompatible-licenses /usr/bin/osgearth_cache LGPLv3+ 
 (libgnutls.so.26) + GPLv2 (libpoppler.so.19)
   osgearth: incompatible-licenses /usr/bin/osgearth_toc LGPLv3+ 
 (libgnutls.so.26) + GPLv2 (libpoppler.so.19)
   osgearth: incompatible-licenses /usr/bin/osgearth_version LGPLv3+ 
 (libgnutls.so.26) + GPLv2 (libpoppler.so.19)
   osgearth: incompatible-licenses /usr/bin/osgearth_viewer LGPLv3+ 
 (libgnutls.so.26) + GPLv2 (libpoppler.so.19)

   tellico: incompatible-licenses /usr/bin/tellico GPLv2 (libpoppler.so.19) + 
 LGPLv3+ (libgnutls.so.26)

No need to file these. Poppler is going GPLv2+3 once next upstream lands
in debian.

/Sune


-- 
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/slrnktqj4m.j8.nos...@sshway.ssh.pusling.com

Re: jessie release goal: verbose build logs

[Sune Vuorela]

On 2013-06-14, Jakub Wilk jw...@debian.org wrote:
 I attached a dd-list for the lazy. But note that false positives are 
 possible, especially when building in parallel.

I've just sample-checked 4 packages I'm involved in and 100% of those
four I checked was false positives.

We need a better detection.

But beside that, I agree with wanting verbose build logs.

/Sune


-- 
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/slrnkrm2nj.j8.nos...@sshway.ssh.pusling.com

Re: systemd .service file conversion

[Sune Vuorela]

On 2013-05-30, Riku Voipio riku.voi...@iki.fi wrote:
 By switching early we can affect how a piece of software will evolve.
 Is there something you would like to change in systemd? Now it still
 probably possible - 2 years from now it has shipped in RHEL, and books
 will have been written about it - and changing it will be much harder.

 So our inability choose early means that we cannot influence the
 community as large - or even our own distribution in long term. While
 we are busy maintaining multiple indirection layers to support user
 choice, the early switching distributions are crafting the software
 that will eventually become the choice.

Wise words.

/Sune


-- 
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/slrnkqe9ja.j8.nos...@sshway.ssh.pusling.com

Re: default MTA

[Sune Vuorela]

On 2013-05-28, Thomas Goirand z...@debian.org wrote:
 I agree. Which is why postfix can be configured for that:

I think most full-blown mta's can do that. But the much smaller ones can
also.

/Sune


-- 
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/slrnkq9mgq.j8.nos...@sshway.ssh.pusling.com

Accepted libiodbc2 3.52.7-3 (source amd64)

[Sune Vuorela]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 17 May 2013 23:08:52 +0200
Source: libiodbc2
Binary: iodbc libiodbc2 libiodbc2-dev
Architecture: source amd64
Version: 3.52.7-3
Distribution: unstable
Urgency: low
Maintainer: Debian QA Group packa...@qa.debian.org
Changed-By: Sune Vuorela s...@debian.org
Description: 
 iodbc  - GTK+ config frontend for the iODBC Driver Manager
 libiodbc2  - iODBC Driver Manager
 libiodbc2-dev - iODBC Driver Manager (development files)
Closes: 640975
Changes: 
 libiodbc2 (3.52.7-3) unstable; urgency=low
 .
   * QA upload.
   * Find odbc drivers in a system dir.
   * Lower relation to iodbc from libiodbc2-dev. (Closes: #640975)
Checksums-Sha1: 
 0f8f9bba0e2b691b029195e614112e8a14429b9d 1258 libiodbc2_3.52.7-3.dsc
 bd5d180b374368e4550d57518b71724834958879 10708 libiodbc2_3.52.7-3.debian.tar.gz
 6bd5916f960effbbdb1d400354deff304d3aa2e0 292528 iodbc_3.52.7-3_amd64.deb
 c9c131b856f882cd7bf2dd75dfca2fe242294739 197536 libiodbc2_3.52.7-3_amd64.deb
 bd4540600db9fdf3d2c62fe7a14ffddc5dc5875a 479144 
libiodbc2-dev_3.52.7-3_amd64.deb
Checksums-Sha256: 
 7c1a33f163423e2d4396372c6f44fea4d824245a35f9c304296ea40d25a89daf 1258 
libiodbc2_3.52.7-3.dsc
 fb8d91ae2efdfae7f469043681f295a9f89b134082d8b0574a1a3aa768fb7d66 10708 
libiodbc2_3.52.7-3.debian.tar.gz
 30e9116f498d0113df2b176a50f0d873a83c440f098660222bb84691898b906e 292528 
iodbc_3.52.7-3_amd64.deb
 5b4e5fcaaf0a33b20df4e25e442547d886cb9d8948048f496c5148d98e199a24 197536 
libiodbc2_3.52.7-3_amd64.deb
 eca4d94b75edefea9d82fe1c715ff24e56366ce542e5e12f4e067dc8f970dbeb 479144 
libiodbc2-dev_3.52.7-3_amd64.deb
Files: 
 4adf12099546a39bcace77dae65987d2 1258 libs optional libiodbc2_3.52.7-3.dsc
 13cd0f19c467ae092d79eea037a9fde4 10708 libs optional 
libiodbc2_3.52.7-3.debian.tar.gz
 5ff85d9e57bf570f33a9045a49b7c24c 292528 misc optional iodbc_3.52.7-3_amd64.deb
 d3bc7d919f0420ab7d08d359b5837911 197536 libs optional 
libiodbc2_3.52.7-3_amd64.deb
 90189da1fd3459115c9699018f3d4982 479144 libdevel optional 
libiodbc2-dev_3.52.7-3_amd64.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlGhQGYACgkQnMvaFgH6i0rCTgCfcmhtZZQziMbdaS/1/dE2ek1E
Rm0AnAw0nqFbDXHdWej+9jdLnu7n0slz
=UDxa
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ugnvl-0003ne...@franck.debian.org

Re: Upgrade path from experimental to unstable

[Sune Vuorela]

On 2013-05-20, Ondřej Surý ond...@sury.org wrote:
 Since the state of Debian experimental is well experimental, should
 we care about upgrade paths from experimental to unstable? I am
 inclined to say no, but I would like to hear opinion of other
 developers.

It depends if you believe you have users or not. It depends if it is
harder to care about the upgrade path than handle helping users getting
stuck and filing weird bug reports.

If it is just a matter of a couple of extra conflicts/replaces, I would
do it. If it requires lots of maintainerscript logic, then I probably
wouldn't.

/Sune


-- 
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/slrnkpk58m.j8.nos...@sshway.ssh.pusling.com