Hi
On 2024-02-16 21:32:49 +0100, Jérémy Lal wrote:
> When a package is uploaded to NEW, you have to upload both the source
> > and binary package(s) for review. After the package is accepted, the
> > buildds auto-build for any other architectures that don't already have
> > a binary package. Mig
Le ven. 16 févr. 2024 à 04:03, Mathias Gibbens a écrit :
> On Thu, 2024-02-15 at 16:20 -0800, Loren M. Lang wrote:
> > Hello,
> >
> > I recently had a package sponsors and entered into unstable called tiv.
> > It can be seen here:
> >
> > https://packages.debian.org/sid/tiv
> >
> > Everything wen
On Thu, 2024-02-15 at 16:20 -0800, Loren M. Lang wrote:
> Hello,
>
> I recently had a package sponsors and entered into unstable called tiv.
> It can be seen here:
>
> https://packages.debian.org/sid/tiv
>
> Everything went OK, but I see that the amd64 arch package appears to
> have been re-buil
Hello,
I recently had a package sponsors and entered into unstable called tiv.
It can be seen here:
https://packages.debian.org/sid/tiv
Everything went OK, but I see that the amd64 arch package appears to
have been re-built for some reason. It's version is showing up with a
+b1. I am curious if
On Mon, Jan 17, 2022 at 10:23:51PM -0800, Ross Vandegrift wrote:
> I guess ITP bugs are common practice for new packages... but are they
> *required* by anything?
No. But your sponsor is likely to request you to file one before
sponsoring.
> It seems like fairly high-friction, low-value work - esp
Hello,
I guess ITP bugs are common practice for new packages... but are they
*required* by anything? It seems like fairly high-friction, low-value work -
especially if you're talking about more than a single package. So I'd like to
avoid it, but I'm not sure what the costs would be.
Thanks,
Ros
Control: tags -1 moreinfo
Hi Leon,
I'm not sure about the status of this RFS / it seems that there is some
confusion… So lets try to untangle this…
What I can see from the diff is that the only package dropped is vim-ascidoc.
This looks sane to me, and due to the fact that vim depends on vim-ru
Before you drop most packages I would suggest you check why they were created
in the 1st place especially the bugs related to the version 8.6.9-4 of the
changelog to avoid recreating the same issues over and over again.
I think you are referencing this point in the changelog:
* asciidoc
Hi,
Before you drop most packages I would suggest you check why they were
created in the 1st place especially the bugs related to the version
8.6.9-4 of the changelog to avoid recreating the same issues over and
over again.
Cheers,
Joseph
i dont see any mess in this packagin , please ! upload and make available
for users to test!+
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
George Shuklin:
> On 05/03/18 14:35, Paul Wise wrote:
>> On Mon, Mar 5, 2018 at 7:08 PM, George Shuklin wrote:
>>
>>> There is a big question with torture me for awhile. Why some purely
>>> declarative operations are performed by non-standard postinst scripts?
On 05/03/18 14:35, Paul Wise wrote:
On Mon, Mar 5, 2018 at 7:08 PM, George Shuklin wrote:
There is a big question with torture me for awhile. Why some purely
declarative operations are performed by non-standard postinst scripts?
Probably dpkg doesn't support declarative mechanisms for
On Mon, Mar 5, 2018 at 7:08 PM, George Shuklin wrote:
> There is a big question with torture me for awhile. Why some purely
> declarative operations are performed by non-standard postinst scripts?
Probably dpkg doesn't support declarative mechanisms for those things.
Some o
Hello.
There is a big question with torture me for awhile. Why some purely
declarative operations are performed by non-standard postinst scripts?
I've checked few well-established packages (openssh, nginx, systemd,
dbus, cups, etc) - each of them have slightly different code for
On Sat, 2016-12-31 at 15:38 +0100, Thibaut Paumard wrote:
> I would believe removing tk8.4 by hand from testing could fix the lot of
> associated autoremovals.
>
> Dear release team, thoughts on that?
tk8.4 and tcl8.4 were already re-removed from testing this morning.
Regards,
Adam
on packages with these RC bugs:
>> 734837: tk8.4: Time to remove from testing
>
> Staden Build-Depends: tk-dev (without any version) and the binary
> package Depends: libtk8.6 (>= 8.6.0) so I do not understand this
> autoremoval message in principle and I specifically wonder why this
ends: tk-dev (without any version) and the binary
package Depends: libtk8.6 (>= 8.6.0) so I do not understand this
autoremoval message in principle and I specifically wonder why this
happens at this point in time.
Staden is juat an example for a set of packages with the same problem.
Kind regar
On 12/21/2016 12:19 PM, Christian Seiler wrote:
> On 12/21/2016 12:04 PM, Andreas Tille wrote:
>> Is bach.hen...@gmail.com the correct address for "contacting wanna-build
>> people"? If yesm Henrik is in CC - if not what's the proper contact?
>
> There's a mailing list for that:
>
> https://list
Hi,
(dropping cc)
On 12/21/2016 12:04 PM, Andreas Tille wrote:
> Is bach.hen...@gmail.com the correct address for "contacting wanna-build
> people"? If yesm Henrik is in CC - if not what's the proper contact?
There's a mailing list for that:
https://lists.debian.org/debian-wb-team/
See also th
Hi Christian,
On Wed, Dec 21, 2016 at 11:46:28AM +0100, Christian Seiler wrote:
> On 12/21/2016 11:37 AM, Andreas Tille wrote:
> >
> > When looking at the build log page[1] I realise that vor some architectures
> > a Build-Depends is missing but I have no idea why for inst
On Wed, Dec 21, 2016 at 10:46:37AM +, Gianfranco Costamagna wrote:
> /tmp/apt-dpkg-install-Pz7ptL/116-r-base-core_3.3.2-1_amd64.deb
> W: No sandbox user '_apt' on the system, can not drop privileges
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> apt-get failed.
>
> so, unless you
>
>
>I did a source upload of r-cran-treescape at 2016-12-19 21:51:35.
>
>When looking at the build log page[1] I realise that vor some architectures
>a Build-Depends is missing but I have no idea why for instance amd64 is
>not build after > 36 hours.
clicking on &quo
On 12/21/2016 11:37 AM, Andreas Tille wrote:
> I did a source upload of r-cran-treescape at 2016-12-19 21:51:35.
>
> When looking at the build log page[1] I realise that vor some architectures
> a Build-Depends is missing but I have no idea why for instance amd64 is
> not build a
Hi,
I did a source upload of r-cran-treescape at 2016-12-19 21:51:35.
When looking at the build log page[1] I realise that vor some architectures
a Build-Depends is missing but I have no idea why for instance amd64 is
not build after > 36 hours.
Any ideas?
Kind regards
Andreas.
Hi
>22 days old (needed 5 days)
>Valid candidate
>
>
>So what might be the problem here?
wild guess, many packages have a dependency on the old version.
but they are arch:all, so binNMU isn't possible (or is, but nobody
wants to try them).
So, sourceful uploads are needed for reverse-
On 09/16/2016 10:01 AM, Andreas Tille wrote:
> So what might be the problem here?
The strict dependencies on sphinx in cdist-doc apparently.
>From the britney output:
Trying easy from autohinter: clustalo/1.2.3-1 sphinx/1.4.6-1
start: 57+556: a-3:i-18:a-0:a-0:a-0:m-0:m-0:p-35:p-0:s-1:m-556
or
Hi,
https://qa.debian.org/excuses.php?package=sphinx
says:
22 days old (needed 5 days)
Valid candidate
So what might be the problem here?
Kind regards
Andreas.
--
http://fam-tille.de
On Sun, Sep 11, 2016 at 09:14:52PM +0200, Jakub Wilk wrote:
> Tell us what the problem was, so that we can learn too.
The text consisted of three paragraphs - one with pure code. I somehow
did not minded / forgot to "translate" the code part. It seems that a
missing paragraph in the translation
* Andreas Tille , 2016-09-10, 07:02:
Found the issue myself, sorry for the noise, Andreas.
Tell us what the problem was, so that we can learn too.
Remark: Enhancements / proof reading of the debconf template text are
welcome as well. Due to the large data set I do not like to change the
text
Found the issue myself, sorry for the noise, Andreas.
On Fri, Sep 09, 2016 at 09:45:19AM +0200, Andreas Tille wrote:
> Hi,
>
> I tried to add translations to the debconf template of metaphlan2-data[1].
> Unfortunately if I call
>
> fakeroot dh_installdebconf
>
> the resulting debian/metaphl
Hi,
I tried to add translations to the debconf template of metaphlan2-data[1].
Unfortunately if I call
fakeroot dh_installdebconf
the resulting debian/metaphlan2-data/DEBIAN/templates is basically a copy
of debian/templates:
$ diff debian/metaphlan2-data/DEBIAN/templates debian/templates
4c
Hi,
On Wed, Aug 31, 2016 at 12:51:57PM +0500, Andrey Rahmatullin wrote:
> On Wed, Aug 31, 2016 at 09:44:59AM +0200, Andreas Tille wrote:
> > I was following the Wiki[1] to get a bitbucket watch for metaphlan2[2].
> > Unfortunately uscan does not detect any match and after starring on the
> > code
On 08/31/2016 09:44 AM, Andreas Tille wrote:
> I was following the Wiki[1] to get a bitbucket watch for metaphlan2[2].
> Unfortunately uscan does not detect any match and after starring on the
> code and trying several other regexp I failed finding the mistake.
>
> Any idea how to get the watch fi
On Wed, Aug 31, 2016 at 09:44:59AM +0200, Andreas Tille wrote:
> I was following the Wiki[1] to get a bitbucket watch for metaphlan2[2].
> Unfortunately uscan does not detect any match and after starring on the
> code and trying several other regexp I failed finding the mistake.
There is no tarball
Hi,
I was following the Wiki[1] to get a bitbucket watch for metaphlan2[2].
Unfortunately uscan does not detect any match and after starring on the
code and trying several other regexp I failed finding the mistake.
Any idea how to get the watch file working and reporting 2.6.0 as latest
version?
n-1.4.2/.pc does not exist.
(It gets created in the course of "dpkg-source --commit" or
"debuild -S". Sometimes it survives the run of "debuild -S".
Sometimes it is gone afterwards. I fail to recognize a pattern.)
This explains why my single patch for 1.4.0-{2,3} work
On Monday 30 November 2015 18:33:22 Thomas Schmitt wrote:
> All is well as long as i have no debian/patches. I can build
> and install the .deb files (debuild -S, debuild -b, dpkg -i).
>
> But if i make changes to the upstream files and run
> debclean
> dpkg-source --commit
> then afterwards
Hi,
after a few weeks of other leisures i came back to Debian
packaging for a new upstream release of my software.
Currently i feel plain stupid because i fail to install
a patch which shall silence a few lintian warnings about
the man pages.
I unpacked the upstream tarball, moved it to the paren
t...@bugs.debian.org|. (Wed, 01 Jul 2015
16:27:14 GMT) Full text
<https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=790771>and rfc822
format
<https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=790771;mbox=yes>available.
Which still leaves my original question: why ?
Try op
library'*Request was from |Bart Martens
> |to |cont...@bugs.debian.org|. (Wed, 01 Jul 2015
> 16:27:14 GMT) Full text
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=790771>and rfc822
> format
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=7
tps://bugs.debian.org/cgi-bin/bugreport.cgi?msg=12;bug=790771;mbox=yes>available.
Which still leaves my original question: why ?
Anyway, I'll prepare an upload to mentors for you Fred.
Cheers,
Ghis
look at the title ;)
RFS for the 2.4-1 version :)
no worry upload to mentors en I will take care of the sponsoring.
Cheers
Fred
> #790771: RFS: clblas/2.4-1 -- OpenCL BLAS library
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Con
On 01/07/15 17:27, Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
which was filed against the sponsorship-requests package:
#790771: RFS: clblas/2.4-1 -- OpenCL BLAS library
It has been closed by Bart Martens .
Their explanation is attached below
Hi,
It'd be better to give pbuilder more love :)
# Probably Junichi is too busy to take care of his children and work.
On Fri, 26 Jun 2015 14:58:57 +
Mattia Rizzolo wrote:
> (btw it's not needed "a local build", `vim /usr/bin/pdebuild` is enough :P)
of course, I did so ;)
--
Regards,
Hi *,
On Thu, Jun 25, 2015 at 10:02:32PM +0200, Andreas Tille wrote:
> On Thu, Jun 25, 2015 at 10:35:49PM +0900, Hideki Yamane wrote:
> >
> > I've changed local pdebuild as
> >
> > -echo "dpkg-buildpackage -S -us -uc -r${BUILDSOURCEROOTCMD}
> > $DEBBUILDOPTS" | \
> > +echo "dpkg-build
On Thu, Jun 25, 2015 at 10:35:49PM +0900, Hideki Yamane wrote:
>
> I've changed local pdebuild as
>
> -echo "dpkg-buildpackage -S -us -uc -r${BUILDSOURCEROOTCMD}
> $DEBBUILDOPTS" | \
> +echo "dpkg-buildpackage -S -d -us -uc -r${BUILDSOURCEROOTCMD}
> $DEBBUILDOPTS" | \
Cool. Do you i
On Thu, 25 Jun 2015 22:35:49 +0900, Hideki Yamane wrote:
> Hm, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786690
Thanks!
> On Thu, 25 Jun 2015 15:14:33 +0200
> gregor herrmann wrote:
> > So you have to pass "-d" (for making the checks non-fatal, i.e.
> > warnings, again, as they were b
Hm, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786690
On Thu, 25 Jun 2015 15:14:33 +0200
gregor herrmann wrote:
> So you have to pass "-d" (for making the checks non-fatal, i.e.
> warnings, again, as they were before), or -nc (don't run clean) to
> dpkg-buildpackage; directly or via --de
On Thu, 25 Jun 2015 14:57:18 +0200, Andreas Tille wrote:
> since I'm back from vacation and upgraded my testing system I realised
> that when using pbuilder the Build-Depends of some package seem to be
> required also on the machine that is creating the pbuilder chroot
> (=where you start pdebuild
> since I'm back from vacation and upgraded my testing system I realised
> that when using pbuilder the Build-Depends of some package seem to be
> required also on the machine that is creating the pbuilder chroot
> (=where you start pdebuild). I regard this a bug but may be I'm missing
> something
Hi,
since I'm back from vacation and upgraded my testing system I realised
that when using pbuilder the Build-Depends of some package seem to be
required also on the machine that is creating the pbuilder chroot
(=where you start pdebuild). I regard this a bug but may be I'm missing
something so b
rstand about
> proper bug handling.
>
The package is orphaned and thus have no "actual maintainer".
There are plenty of reasons why the previous maintainer might not have
closed the bug. The most common/likely one being that he/she simply
forgot about it (and happened to retire before
On Tue, Jun 02, 2015 at 06:10:24PM +, Thaddeus H. Black wrote:
> A bug is years old. It will probably not be fixed. It should probably not
> be fixed. It is probably not even a bug.
>
> The bug's submitter is not complaining.
>
> Why is the bug still open?
&g
A bug is years old. It will probably not be fixed. It should probably not be
fixed. It is probably not even a bug.
The bug's submitter is not complaining.
Why is the bug still open?
Example: #619363. [1]
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619363
If I wer
I got it.
Thank you,
Santiago, Jakub, Johannes, Mattia and Wookey !
:)
--
Regards,
C.D.Luminate
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1432439429.714
* Wookey , 2015-05-22, 19:08:
override_dh_auto_build:
# well. let's copy config back again.
cp ./debian/my/Makefile.config.cpuonly ./Makefile.config
debian/my/00-fix-caffe-include-path-debian.sh
$(MAKE) all
$(MAKE) test
$(MAKE) runtest
also, that
+++ Mattia Rizzolo [2015-05-22 17:04 +0200]:
> On Fri, May 22, 2015 at 6:31 AM, lumin wrote:
> > override_dh_auto_build:
> > # well. let's copy config back again.
> > cp ./debian/my/Makefile.config.cpuonly ./Makefile.config
> > debian/my/00-f
On Fri, May 22, 2015 at 6:31 AM, lumin wrote:
> override_dh_auto_build:
> # well. let's copy config back again.
> cp ./debian/my/Makefile.config.cpuonly ./Makefile.config
> debian/my/00-fix-caffe-include-path-debian.sh
> $(MAK
Hi,
Quoting lumin (2015-05-22 06:31:34)
> override_dh_auto_clean:
> cp ./debian/my/Makefile.config.cpuonly ./Makefile.config
> dh_auto_clean
> # without following line the the source tree
> # would be not clean. Hence dpkg-bu
Hi mentors,
I solved this problem, after line-by-line reviewing the
screen output of those commands.
It turns out that, the "clean" target of Makefile
needs the Makefile.config too.
this rules file makes dpkg-buildpackage continue building.
(I deleted some comments )
Hi,
I modified the debian/rules[1] according to
Santiago and Jakub (thank you both!),
and tested again. The result was the same.
"dh build" works while "dpkg-buildpackage" doesn't.
[1] --- the whole debian/rules
1 #!/usr/bin/make -f
2 # See debhelper(7) (
* lumin , 2015-05-21, 14:30:
I'd like to take over the whole build process, so I wrote:
32 override_dh_auto_build: build_cpuonly
33
34 build_cpuonly: config_cpuonly
35 $(shell debian/my/00-fix-caffe-include-path-debian.sh)
As Santiago noticed, you should alm
On Thu, May 21, 2015 at 02:30:58PM +, lumin wrote:
> I'm trying to package caffe as said [1] at debian-science@ .
> However I encountered a problem when writing debian/rules.
>
> I'd like to take over the whole build process, so I wrote:
>
> 32 override_dh_auto_build: build_cpuonly
>
Hi mentors,
I'm trying to package caffe as said [1] at debian-science@ .
However I encountered a problem when writing debian/rules.
I'd like to take over the whole build process, so I wrote:
32 override_dh_auto_build: build_cpuonly
33
34 build_cpuonly: config_cpuonly
On 2014-10-25 13:00, Andreas Tille wrote:
> Hi,
>
> https://qa.debian.org/excuses.php?package=beast-mcmc
>
> says:
>
> beast-mcmc/i386 unsatisfiable Depends: libnucleotidelikelihoodcore0 (>=
> 1.8.0-1)
>
> but I have asked ftpmaster for removal of beast-mcmc from arch i386 and
> packages.de
Hi,
https://qa.debian.org/excuses.php?package=beast-mcmc
says:
beast-mcmc/i386 unsatisfiable Depends: libnucleotidelikelihoodcore0 (>=
1.8.0-1)
but I have asked ftpmaster for removal of beast-mcmc from arch i386 and
packages.debian.org says it is only for amd64. Any idea how to enable
the
* Andreas Tille , 2014-08-14, 10:48:
I'm goggling on
https://release.debian.org/migration/testing.pl?package=libcofoja-java
This script might be a bit confused.
so we have *both* 1.1-r150-1 and 1.1-r150-2 in unstable. I have no
idea how this can happen. Any clue?
libcofoja-java_1.1-r15
Hi,
I'm goggling on
https://release.debian.org/migration/testing.pl?package=libcofoja-java
and have no idea what might be wrong here. A cause for this riddle might be
$ LANG=en apt-cache policy libcofoja-java
libcofoja-java:
Installed: (none)
Candidate: 1.1-r150-2
Version table:
> Date: Wed, 12 Feb 2014 22:22:47 +0600
> From: w...@wrar.name
> To: debian-mentors@lists.debian.org
> Subject: Re: why does gnome-based packages builds fine with cbds and not with
> dh7
>
> On Wed, Feb 12, 2014 at 02:04:31PM +
On Wed, Feb 12, 2014 at 02:04:31PM +, Roelof Wobben wrote:
> I have tried to build 2 packages from Cinnamon ( a gnome-based DE)
>
> When I do debuild on the by upstream made cdbs rules file both compiles fine.
>
> When I try to rebuild them by using dh7 which I like more then I see a lot of
Hello,
I have tried to build 2 packages from Cinnamon ( a gnome-based DE)
When I do debuild on the by upstream made cdbs rules file both compiles fine.
When I try to rebuild them by using dh7 which I like more then I see a lot of
build-problems
Like a directory cannot be build because of permis
> > Why is it so hard to get sponsor and why is there nobody who tries to
> > support the jabber uploads ;)
> Well, as I am in the same shoes, we can make a deal. We can try to
> review each other's packages, trying to fix bugs and give
> recommendations supporting each
the packages will stay in bad shape.
I have got very similar experience. It is not easy to find a DD to
sponsor you.
Why is it so hard to get sponsor and why is there nobody who tries to
support the jabber uploads ;)
Well, as I am in the same shoes, we can make a deal. We can try to
review each
My guess is that the intersection between people who have upload
access, experience, time, interest in running an XMPP server, aren't
already running other XMPP server software and are reading this list
is close to zero.
Daniel Pocock has been blogging about XMPP, federated services and
other rela
Hi Members,
Last February I mailed the list why some packages wont get a sponsor. I
got a few reactions of sponsors
who helped me to get the package into decent shape. But at the end no
sponsor would have time or experience with
the package to upload it. The jabber packages are obvious a strange
On 02/27/2013 06:41 AM, Paul Wise wrote:
Bah, I need to read before sending.
Very nice response Paul, I think it's worth adding to FAQ:
http://wiki.debian.org/DebianMentorsFaq#Why_is_it_so_hard_to_find_sponsor.3F
I've updated "What happens if I can't find a sponsor" as well.
cheers,
Tomek
On Thu, Feb 28, 2013 at 11:21 PM, Charles Plessy wrote:
>
> Hi Lenz,
Cheers
>
>
> with time, DDs tend to meet loved ones,
i have too, also I have a couple, just one, not several, and I am
responsible .. a'n my loves use in mayority linux, not window-like
over linux
>
> make children, be promoted
Le Thu, Feb 28, 2013 at 01:04:39PM -0430, PICCORO McKAY Lenz a écrit :
>
> I've noticed that some reports have response as "is not critical, is still
> working," or else "not reproducible", or better "u can made a patch u can
> made a fix u ca... u can.. u do that" co DD/DM has no time!! NO TI
a patch u can
made a fix u ca... u can.. u do that" co DD/DM has no time!! NO TIME!??
one can see that many DD have no experience in the software packages nature
in charge .. l this is main reason why the quality / performance of debian
packages has fallen, and because these characte
Hi Paul,
thanks for your great analysis. I might like to stress explicitly one
item (even if I totally agree with all others in general)
On Wed, Feb 27, 2013 at 01:37:10PM +0800, Paul Wise wrote:
> Specialization:
>
> Debian contributors generally work on stuff they use or are otherwise
> are i
On 27.02.2013 20:57, Anton Gladky wrote:
>> First - a weighted sponsorship priority queue - all packages get a
>> rating and higher-rated packages will get sponsored sooner than others.
>
> I agree with that. On my opinion the package "weight" should be
> calculated, considering the following par
as "please, fix it".
I've seen comments about packages requesting sponsorship like "why do we
need yet another foo package".
Duplicating functionality already in Debian is one reason to mark down a
sponsorship request - I'm sure there are others.
Cheers,
Anton
--
To U
On 02/26/2013 10:36 PM, Paul Tagliamonte wrote:
> it is currently during freeze, most DDs are working on RC
> bugs :)
If only this was truth! :)
Thomas
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.o
Hi all,
my 2 cts.
On 02/27/2013 12:07 AM, Philip Ashmore wrote:
>
> First - a weighted sponsorship priority queue - all packages get a
> rating and higher-rated packages will get sponsored sooner than others.
I agree with that. On my opinion the package "weight" should be
calculated, considerin
I'm reminded of the metrics stuff that was discussed ages ago:
https://wiki.debian.org/DebianMentorsNet#Metrics
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.
On Tue, Feb 26, 2013 at 11:07:11PM +, Philip Ashmore wrote:
> On 26/02/13 21:51, Arno Töll wrote:
> >Hi,
> >
> >On 26.02.2013 22:31, W. van den Akker wrote:
> >>I understand [1] and [2]. I meant uploading to unstable and not testing.
> >>But none of the DD was ever answering the emails..
>
Bah, I need to read before sending.
On Wed, Feb 27, 2013 at 1:37 PM, Paul Wise wrote:
> Specialization:
...
> Unfortunately can mean
Unfortunately this can mean there are no sponsors for particular areas.
> Preferences:
>
> Different folks have different packaging preferences, some like cdbs,
Here is a hopefully comprehensive, general answer to this question,
not specific to your situation:
Freeze:
During the release freeze, most Debian folks are focussed on getting
the release out. Fixing RC bugs, fixing important bugs, doing upgrade
testing, writing release notes, finalising the ins
On 26/02/13 21:51, Arno Töll wrote:
Hi,
On 26.02.2013 22:31, W. van den Akker wrote:
I understand [1] and [2]. I meant uploading to unstable and not testing.
But none of the DD was ever answering the emails..
Be patient and don't give up. I know this can be frustrating and
annoying, and w
Hi,
On 26.02.2013 22:31, W. van den Akker wrote:
> I understand [1] and [2]. I meant uploading to unstable and not testing.
> But none of the DD was ever answering the emails..
Be patient and don't give up. I know this can be frustrating and
annoying, and we're slowly trying to improve the si
> If I am reading your (big) changelogs correctly, you are (amongst other
> things) switching patch-system to quilt, and package new upstream
> versions - This is a big no-no for the release team during the freeze
> (see [1]) which we have had since June [2].
>
> This might lower the chances of g
> While this isn't true of the general case, which I think there's valid
> concern about, it is currently during freeze, most DDs are working on RC
> bugs :)
Ok.
>
> Some sponsorship does still go on -- perhaps you could ask some of the
> DDs who maintain jabber servers -- the ejabberd folks or
d to be interested in sponsoring them.
>I got messages not familiar with these packages or something like
>that.
>
>In the past I had some other packages and also had problems to get a
>sponsor.
>
>Why is it so hard to get a sponsor?
>
If I am reading your (big) change
emed to be interested in sponsoring them.
> I got messages not familiar with these packages or something like that.
>
> In the past I had some other packages and also had problems to get a sponsor.
Yeah, me too. Even as a sponsored uploader & a DM.
>
> Why is it so hard
something like
that.
In the past I had some other packages and also had problems to get a
sponsor.
Why is it so hard to get a sponsor?
Greetings,
Willem
signature.asc
Description: This is a digitally signed message part
g of
>> packages that have gone through tpu recently (e.g. cdbs, underscore,
>> etc.).
>
> Sure, I'm not disputing that. I'm just saying that the bug report doesn't
> really help.
It helps because it has the origin, reasoning, history, and context
for the move to
Mike,
On Sun, Dec 02, 2012 at 04:36:23PM -0500, Michael Gilbert wrote:
> Yes. I don't have a link to the final decision, but you can easily
> verify the veracity of that statement by looking at the versioning of
> packages that have gone through tpu recently (e.g. cdbs, underscore,
> etc.).
Sure
On Sun, Dec 2, 2012 at 4:31 PM, Ivo De Decker wrote:
> Hi Mike,
>
> On Sun, Dec 02, 2012 at 03:20:25PM -0500, Michael Gilbert wrote:
>> > Well, I thought this was only the case when there is no other option,
>> > because
>> > the version has to be smaller than the one in unstable (when testing has
Hi Mike,
On Sun, Dec 02, 2012 at 03:20:25PM -0500, Michael Gilbert wrote:
> > Well, I thought this was only the case when there is no other option,
> > because
> > the version has to be smaller than the one in unstable (when testing has
> > 4.3.6-1 and unstable has 4.3.6-2 with unacceptable chang
> Well, I thought this was only the case when there is no other option, because
> the version has to be smaller than the one in unstable (when testing has
> 4.3.6-1 and unstable has 4.3.6-2 with unacceptable changes). I did a t-p-u
> update like this (without the deb7u suffix) yesterday (for fossil
1 - 100 of 459 matches
Mail list logo
