wondering if there is something Debian can do to be even more
> successful in the container world.
You could use dck-buildpackage --create-baseimage to do that.
Feel free to create some target configs, and I'll be happy to add them.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded e
ependencies already installed - but I don't like manual things :o)
BTW: one important point w/ dck-buildpackage for me was being able
to specifiy what's in the image. I really prefer to have it really
minimal.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineer
w/ k8s ...
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
On 05.10.19 03:31, Paul Wise wrote:
> On Fri, Oct 4, 2019 at 10:49 PM Enrico Weigelt wrote:
>> On 24.07.19 08:17, Marc Haber wrote:
>>
>>> Do we have a build technology that uses containers instead of chroots
>>> yet?
>>
>> Something like docker-bu
On 24.07.19 08:17, Marc Haber wrote:
> Do we have a build technology that uses containers instead of chroots
> yet?
Something like docker-buildpackage ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
igured installations.
One thing seems to be right: folks who always have been hostile towards
the whole concept of distros now have a better excuse.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
e can also release
> build
> dependency updates via stretch-security).
ACK. I haven't had a chance to take a deeper look at the rust/cargo
issue yet (currently too occupied with other things). If anybody could
come forward with a solution, I'd be really glad.
--mtx
--
Enrico Weigelt, metux I
this ...
> The AppStream metadata format includes a field for "hardware this works
> with", and beignet-opencl-icd has one, but I don't know if any existing
> tools use this field.
I don't like the idea of making driver packages depending
on some desktop stuff :o
IMHO, it shou
On 01.07.19 21:06, Enrico Weigelt, metux IT consult wrote:
Hi,
> IIRC the whole things is actually about crypto stuff. Why don't zfs> folks
> just use the standard linux crypto api (potentially introduce a>
new algo if the existing ones aren't sufficient) ?
Addendum: just had
as far as I remember).
IIRC the whole things is actually about crypto stuff. Why don't zfs
folks just use the standard linux crypto api (potentially introduce a
new algo if the existing ones aren't sufficient) ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineeri
pplications that treat "no hardware for this driver" as "fatal error"
> instead of "try the next driver".
So, installing an opencl-based package pulls in *all* cl driver stacks ?
Please don't do that. This IMHO clearly belongs into the operator's
hands (or possibly s
bianized branch) and publishes the repos to the outside world,
would be a really cool thing for me. IIRC that should also cover this
'scratch builds' usecase.
I admit, I haven't checked whether gitlab-ci can already do that.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedde
On 01.07.19 15:09, Andrey Rahmatullin wrote:
> On Mon, Jul 01, 2019 at 03:04:26PM +0200, Enrico Weigelt, metux IT consult
> wrote:
>> On 29.05.19 17:41, Andrey Rahmatullin wrote:
>>
>>>> Perhaps we should update policy to say that the .orig tarball may (or
>>
ld be better to just differenciate the statistics between
official debian and others (such as downstreams).
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
adable git repo and makes
interacting w/ upstream (eg. submitting patches) unncessarily hard.
That's something I regularily see w/ crappy vendor kernels, which then
take lots of time to bring them into some somewhat usable state :o
--mtx
--
Enrico Weigelt, metux IT consult
Free software and
le process
(eg. fully automatic, easily reproducable transformations)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
idiered "applicable" (or better: when is it okay not doing
that) and some rules on how the generation process shall be done.
(maybe having some script with a defined name ?)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
some more details on the intended workflow ?
Why does one need that information at all ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
o
> record what the most recent rebase is. Obviously I prefer
> git-debrebase since I wrote it - using a different data model - even
> after I knew about git-dpm and its data model. But maybe this isn't
> the thread for that advocacy conversation.
What exactly does this tool do ?
we could figure out a way to collaborate on something like that well,
> it might be a very interesting tool to have.
ACK.
I believe we should set some computable policies on how orig trees are
generated from actual upstream repos and patches are handled, so we can
do imports/transformations fully aut
ll required to produce a .dsc.
I don't think that .dsc really makes the picture so different. It always
can be generated automatically. IMHO, it's only needed as an output
format for creating src repos and as an intermediate transport for
traditional tools like buildd.
--mtx
--
Enrico Weigel
tary userland interface can't be accepted for mainline - it
has to be reworked to be conformant w/ standard uapi (eg. we already
have it for things like snapshots, deduplication, quotas, ...)
But it's up to ZoL developers to do the actual work and post patches
to lkml. There won't be anybody else doing that.
ours, etc. - instead I'm using separate layer 2 branches
for that.
(for maintaining lots of kernel configs based on some meta config, I've
got a separate tool)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
just
basing on their release tags. And, of course, there shouldn't be
anything autogenerated in the git repo - always recreate everything
(*especially* autotools-generated stuff). The orig tarball, IMHO, is a
long obsolete ancient relic.
For upstreams that don't have a git repo yet, I setup an
success, so I just gave up :(
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
intainers was asymptotically
approaching zero, from below.
> Enrico Weigelt, metux IT consult writes ("Re: Survey: git packaging practices
> / repository format"):
>> I'm always cloning the upstream repo, branch off at their release tag
>> and add all necessary chanages a
ome
the generic (non-deb specific) patches, then the deb specific ones.
No text-based patches, or even magic rewriting within the build process.
The HEAD is exactly the debianized source tree, which is then fed to
dck-buildpackage.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linu
ack source tree plus debian/, some w/ extra text-based patches,
some w/ patches already applied in git.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
rd upstreams in my list...
Maybe we should talk about some of these cases, to get a better idea.
In general, we IMHO should rethink the workflows for creating the actual
buildable debian tree from upstream releases (in many packages that's
still pretty manual and hackish)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
erything from a debianzed source
tree (eg. git repo) within a minimal container/jail, w/o any other extra
configuration outside that source tree - even for those cases where the
control file needs to be generated, which again needs some deps.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
hich is used by my build machinery
(dck-buildpackage) in a separate preparation step, when control file
is missing.
But still, IMHO, the debian packaging toolstack is much superior to
anything else i've every encountered.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linu
Okay, it's just a dream, but a very nice one ;-)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
IMHO not in official Debian
repo, but I've got it hanging around in some 3rdparty repo ...
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
On 19.11.18 20:24, gregor herrmann wrote:
> On Mon, 19 Nov 2018 17:29:37 +0100, Enrico Weigelt, metux IT consult wrote:
>
> (OT, but since I noticed it too:)
>
>> Anyways, Skype doesn't work since 8.30 as it crashes directly on
>> startup.
>
> Apparently it need
y code changes outside
git, and I'm building packages only directly from git. Frankly, I don't
see any reason why that can't be the standard case.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
haviour.
hmm, looks like good start. But it doesn't really look easy to clone
from different distros and specific or yet unreleased versions.
and one of my main problems remains unresolved: linear history ontop
of the upstream's release tag.
--mtx
--
Enrico Weigelt, metux IT consult
Free so
tworthy code them into a minimal container
w/ fine tuned minimal permissions.
Anyways, Skype doesn't work since 8.30 as it crashes directly on
startup.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
re and there, it still far away from an
fully-automated process.
I'm currently helping myself w/ lots of mappings and import scripts,
but I'd like to get rid of maintaining all these little pieces.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
cases where upstream history is
extremely huge - like mozilla stuff) would be just branching at the
upstream's release tag and adding commits for removing the non-dfsg
files ontop of that. From that branching the debianized branch,
where all patches are directly applied in git.
--mtx
--
Enrico
sure that
nothing in that really complex cmake file can even try build/use any
piece of them.
the package was just meant for an inhouse installation for my client,
so i didn't care much about policies and orig tarball handling - I've
just patched directly in the git repo.
--mtx
--
Enrico Weigelt
affected packages.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
en and unusable anyways - for several
month now. We could reconsider once the Upstream (Microsoft) manages
get it at least running w/o segfaulting.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
bad quality or even malicious.
Finally, I'd really like to reduce complexity, not introduce even more.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
some local customizations.
(planned for future releases)
I'm also hacking on another tool which automatically clones repos
and calls dck-buildpackage for building whole pipelines - but that's
still experimental and hackish:
https://github.com/metux/deb-pkg
--mtx
--
Enrico Weigelt, metux
ations, eg. moz).
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287
Hi folks,
is it possible to use the substvars mechanism for the *.install and
similar files, just like w/ control file ?
For multi-version installations, I'm keeping the whole package in a
prefix w/ the version number (see my other mail - nodejs). I don't like
to change lots of files which
On 04.05.2017 09:26, Jérémy Lal wrote:
> At the moment, in debian, /usr/lib/nodejs is there to store all node
> modules installed from debian packages.
hmm, would that conflict w/ having certain "nodejs-$version" subdirs
w/ the actual engines (the whole tree - not splitted out the several
FHS
Hi folks,
I'm currently packaging nodejs-7.9 for various deb Distros.
I'll have to maintain some applications that use the fanciest
new features, and precompiled binaries from untrusted sources
(eg. nvm+friends) of course are not an option.
Before I go all of this alone - is there anybody here
On 14.04.2017 14:34, ian_br...@mail.ru wrote:
> I was right -- it IS a Debian Policy violation:
>
> * 4.13 Convenience copies of code *
I've got a similar problem while packaging recent webkit (latest surf
needs a newer one). Their git repo is >GB (!). No idea how much I'll
have to cut out
On 13.04.2017 11:27, Vincent Danjean wrote:
> For me, the first argument explain in the first mail is not this one.
> systemd is not portable on lots of system (hurd, kFreeBSD, ...),
This is just one of many arguments for not making applications
depending on it. (and they shouldn't depend on
On 17.02.2015 18:49, The Wanderer wrote:
Hi folks,
just digging out an older thread that was still laying around in my
inbox - w/ about 2yrs distance, I hope it was enough cool down time
so we discuss it more objectively about that.
> libsystemd0 is not a startup method, or an init system.
On 11.04.2017 10:22, Andrey Rahmatullin wrote:
> On Tue, Apr 11, 2017 at 04:22:40AM +0200, Enrico Weigelt, metux IT consult
> wrote:
>>>>
>>>>
>>>> could anyone please give me some insight, was the security problems
>>>> are here exactly ?
&
On 09.04.2017 22:58, Andrey Rahmatullin wrote:
> On Sat, Apr 08, 2017 at 08:28:38AM +0200, Enrico Weigelt, metux IT consult
> wrote:
>>
>>
>> could anyone please give me some insight, was the security problems
>> are here exactly ?
> Extension auto-updating is
could anyone please give me some insight, was the security problems
are here exactly ?
--mtx
--
mit freundlichen Grüßen
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287
?
See:
https://github.com/metux/fskit/tree/jessie/master
https://github.com/metux/fskit/tree/trusty/master
the build process is driven by:
https://github.com/metux/packaging
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUBSCRIBE, email to debian-devel-requ
On 02.01.2015 17:08, Martin Pitt wrote:
Hi,
Yes, man dh_fixperms. Shared libraries don't need to and should not be
executable.
Oh, wasn't aware of that. Just used to that as gcc sets that flag.
Is it a bug in gcc, or are there platforms where +x is required ?
cu
--
Enrico Weigelt,
metux
On 25.11.2014 16:29, Philip Hands wrote:
How is it that Debian changing the default for something on some of
What about the enforced replace on dist-upgrade, which at least
produces lots of extra work and can easily cause systems being
unbootable ?
cu
--
Enrico Weigelt,
metux IT consulting
On 29.11.2014 19:15, Svante Signell wrote:
Since there is no interest in adding a debconf message on new installs,
I wish for a menu entry in the advanced part of the installer to be able
to install a new system with sysvinit-core or upstart!
+1
--
mit freundlichen Grüßen
--
Enrico
the impression that these guys
still value traditional unix concepts, like using the filesystem
for simple hierarchical data structures and access control, tiny
and easily compositable servers and tools, etc.
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUBSCRIBE, email
GNOME originally have the intention of being
crossplaform, not Linux-only ?
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https
wrote muxmpm, which ran
individual sites under their own uid/gid, chroot, etc. That made things
like cgixec, php's safe_mode etc practically obsolete.
It was even shipped by several large distros, eg. suse (the orignal
one, not novell).
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
like
perfectly reasonable and useful feature to me.
Okay. But WebDAV would be one of the last protocols, I'd consider
for that (maybe for the wide internet, but not for local networks).
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUBSCRIBE, email to debian-devel-requ
with arbitrary UIDs, and how much overhead copying between
processes (compared to socket-passing) produces on modern systems
(back when I wrote muxmpm, it still was quite significant)
OTOH, for high-volume scenarios, apache might not be the first choice.
cu
--
Enrico Weigelt,
metux IT consulting
+49-151
ever going into my system -
instead of replacing it later (eg. some option in the installer) ?
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
would even question, why each DE needs it own display manager ?
What's so wrong with all the other DMs ?
Certain DEs (like GNOME and KDE) seem trying to build their own
operating system - I really fail to understand why.
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
. If there really is some functionality which some DEs
really need, why not having an entirely separate tool for that ?
Anyways, I still didn't understand why udev is bundled within systemd.
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
To UNSUBSCRIBE, email to debian-devel-requ
faction ?
cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287
--
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/54812e53.9080...@gr13.net
On 27.11.2014 02:18, Josh Triplett wrote:
gnome Depends: gnome-core, which Depends: gnome-user-share, which
Depends: apache2-bin (or apache2.2-bin in stable, which is a
transitional package depending on apache2-bin in unstable).
gnome depends on apache ?
seriously ?
cu
--
Enrico Weigelt
will continue to provide the existing alternatives, including
fresh installation (choosable at installation time, or separate
installer images)
c) the init system will never be switched w/o _explicit_ order
by the operator
d) this decision stands until explicitly revoked
cu
--
Enrico Weigelt
git-buildpackage.
Uploaded it to github, maybe somebody likes to have a look at it:
https://github.com/metux/wwwoffle/
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig
a signed tag (to the debianized branch) and let the
machinery run ;-)
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427
Hi folks,
just seen that the German translation of the maintainer guide is
quite incomplete.
Perhaps I could find some time for fixing it, if anybody explains
me how to do that ;-)
cu
--
--
Enrico Weigelt, metux IT service
me
know what should be done here.
thx
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
* Fernando Lemos fernando...@gmail.com schrieb:
Are you guys applying for maintainership for this huge delta
you want to introduce between upstream and us?
Actually, yes.
cu
--
--
Enrico Weigelt, metux IT service -- http
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
* Tanguy Ortolo tanguy+deb...@ortolo.eu schrieb:
Enrico Weigelt, 2011-12-31 03:55+0100:
IMHO this is completely wrong, those files should be under
/usr/lib/... or maybe even /usr/share/... as they're not
dynamic data.
Well, when people install new plugins or new themes, they get
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
, without operators used to look at /etc
and comparing current config with new defaults.
Not sure how Debian handles this, but Gentoo's etc-update
mechanism has shown to be very handy.
cu
--
--
Enrico Weigelt, metux IT service
them up)
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
* Tanguy Ortolo tanguy+deb...@ortolo.eu schrieb:
Enrico Weigelt, 2011-12-30 06:21+0100:
Which packages ship files in /var ?
Many install directories there. And one of my packages, dokuwiki, also
installs files under /var/lib/dokuwiki/lib/{plugins,tpl}. These files
define the default set
. Sometimes the distro maintainers
have to bite in the bitter apple and cleanup upstreams's dirt.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49
problem are the uncountable
existing systems which might become troublemakers with that change.
We need practical and reliable migration strategies first.
In the end, I'm curious if it's really worth all of this.
cu
--
--
Enrico
we could do in this regard is to move some stuff from
/usr to /usr/share or some other tree that is more convenient for placing on
a
different filesystem.
What exacty do you intend to put to /usr/share ?
cu
--
--
Enrico
Things have changed a lot since the FSSTD first came out.
True. But the need for quick and easy system maintenance remains.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux
as an synthentic filesystem. The
interesting question is how this behaves on high-load scenarios.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile
alone and do the redundant fixes (which distros still
are doing alone, just for themselves, again and again) in one
dedicated project where distros then can pull from.
cu
--
--
Enrico Weigelt, metux IT service -- http
, but often can give good hints where
there *might* be some bug. So, IMHO, maintainers should always enable
them for testing and try to fix the problems.
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone
from glibc and pam. That would
also solve the static linking problem.
Perhaps something like Plan9's factotum ?
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
* Tollef Fog Heen tfh...@err.no schrieb:
]] Enrico Weigelt
| Autoconf (w/o automake) offers no means to tell additional m4
| include pathes (eg. in configure.ac), so that just calling
| autoreconf (w/o any additional parameters!) can do a full
| regeneration all on its own.
What's wrong
to pull it through my own embedded QM process and
build machinery first, so we'll also get crosscompile fixups etc
as a buy-product here ;-)
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207
)
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
--
Embedded-Linux
a common interface, which (for autoconf'ed
packages) looks like this:
#1: ./autogen.sh
#2: CC=.. LD=.. ... ./configure feature-flags
#3: make
#4: make DESTDIR=... install
cu
--
--
Enrico Weigelt, metux IT service -- http
purposes only. Generally don't find
tags useful in upstreams.
Ah, okay, now it starts clearing up to me ...
You're using a file-based VCS ?
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207
own.
Right ?
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
near that level of importance.
Probably not. But why not learning from the other areas of engineering ?
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
* Neil Williams codeh...@debian.org schrieb:
(forgot attachments)
...
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weig...@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
to upstreams.
I've already done that for several packages in the OSS-QM project.
(which is not meant for Debian, but completely distro agnostic)
cu
--
--
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207
1 - 100 of 147 matches
Mail list logo
