On Thu, 24 Sep 2015, Marvin Renich wrote:
> How does failing the upgrade solve anything? The upgrade should only
> fail if the failure of the service to start was because something in the
> upgrade itself was broken; this is rarely the case.
...
> What makes this even worse is that when installi
On Thu, 24 Sep 2015, Santiago Vila wrote:
> You don't appreciate the beauty of simplicity.
FOR binNMUs:
* I do appreciate not triggering a libreoffice rebuild on the slow arches when
a binNMU is required on amd64.
AGAINST binNMUs:
* I do appreciate multiarch not being broken by binNMU'd pack
On Sat, 05 Sep 2015, Matthias Klumpp wrote:
> 2015-09-05 3:49 GMT+02:00 Osamu Aoki :
> > [...]
> > >2. In addition to those changes, the Technical Committee resolves
> > > that packages providing a .desktop file shall not also provide a
> > > menu file for the same application.
> >
hem all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
ind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
whatever reason).
Someone that really cares about this should step up and claim the
debian-on-hv hat ;-)
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
l, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On Fri, 10 Jul 2015, Boris Pek wrote:
> > But I am shocked to find this software being ported into stable
> > packages, while it can do nothing.
>
> YAGF v0.9.3.2 works fine except one well known bug (see #746380).
> And this issue will be fixed in the next upload of the package.
Please arrange f
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lis
On Fri, 29 May 2015, Russ Allbery wrote:
> Philipp Kern writes:
> > Perfect is the enemy of good. Debian is already paying the protection
> > money at this point and TBH I don't understand the resistance to add
> > and promote the https:// variant of it. We can still switch to Let's
> > Encrypt on
t using 'you'), I suppose.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
--
To UNSUBSCRIBE,
le them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.
On Tue, May 26, 2015, at 15:25, Vincent Bernat wrote:
> ❦ 26 mai 2015 14:38 -0300, Henrique de Moraes Holschuh
> :
>
> >> A solution to this without history rewriting is to tag the commits you
> >> want to sign.
> >>
> >> You could tag any commit a
ave a meaningful comment/message for the signed tag,
because it can be duplicated/renamed at will.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley
ing out
> that this is a security hole:
> https://bugs.freedesktop.org/show_bug.cgi?id=89682
https for git access is not what you should be asking out of
freedesktop.org, IMO.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grin
annot trust signed tag names, just
contents (such as the tag message).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
r pushed/merged?
How do you ensure that every branch which doesn't have a signed tag for
their top commits are trusted, especially in remote copies?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Re
some of them are actively enforced last
time I checked.
Has the situation changed?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de
On Sat, 09 May 2015, Josh Triplett wrote:
> The on-disk persistent journal (/var/log/journal) is disabled because at
> the moment, Debian systems use syslog by default (via rsyslog), and
> enabling the persistent journal would result in two copies of log
> messages.
>
> Since the journal is capabl
an and Ubuntu-friendly, and target also the LTS
branches of Debian and Ubuntu. This side-steps all the issues I raised.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie."
and non-sucessful use of rnetclient 2015.1 in our mailing
list".
Please clarify the above points. So far, it looks like accepting this in
Debian is a lot of risk for no real gain.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness gr
t; +0200
>
> but I wonder why a policy of package B would dictate a A->B dependency.
Because package B is one of the target users of the functionality provided by
package A.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkne
t; for library transitions to get in sync, etc) and get some ideas for
> those things. Otherwise, nothing much jumped out at me...
I think I will put forward a proposal for the -stable side of this, but
it will be far more geared toward human processes than the automation
side of things.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond where
the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes
Holschuh
the maintainer can check the results for
any trojans that might have crept in (i.e. there is no difference from what one
is already supposed to do with any new source release from upstream), there is
no problem.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list
"20" and the "10" to something that fits well the width
of your text terminal.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley
On Tue, Mar 31, 2015, at 10:22, Stefano Zacchiroli wrote:
> On Tue, Mar 31, 2015 at 10:18:50AM -0300, Henrique de Moraes Holschuh wrote:
> > apt-get is the simple tool everyone knows about, though. It also needs
> > another simple tools like apt-cache to be really usable.
>
&g
grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
apt toolset in "standard".
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh
--
To UNSUBSCRIBE, email
On Wed, 10 Dec 2014, Maciej Kotliński wrote:
> Finally I found the easiest and trivial resolution of the problem. You
> just can set scope 0 with ip command.
>
> The interface with address 169.254.x.x gets scope link (253), so the
> packets won't be send outside NAT. Configuring interface with i
On Tue, 09 Dec 2014, Maciej Kotliński wrote:
> You don't understand what I mean. The gateway is forwarding packages!
> It is forwarding packages from Windows, Mac, and other Linux boxes
> in 169.254.x.x
The gateway is doing something it was not supposed to do in the first place.
> Debian Jessie b
On Tue, 09 Dec 2014, Maciej Kotliński wrote:
> It is possible to ping the gateway and other computers in 169.254.1.0/24
> network. The packets are not routed by the nat.
link-local addresses, such as 169.254.0.0/16 are "unroutable". No traffic
from/to link-local addresses is allowed to go "throug
On Tue, 09 Dec 2014, Maciej Kotliński wrote:
> I have a NAT-ed network which uses 169.254.1.0/24 range (private/zeroconf
> range). The network has dhcp and gateway (169.254.1.1). From some time
> (probably few months) Debian Jessie is not able to use the gateway.
This was never supposed to work in
On Fri, 21 Nov 2014, Vincent Bernat wrote:
> ❦ 21 novembre 2014 17:34 -0200, Henrique de Moraes Holschuh
> :
> >> I thought there was a flag bit you could set on x86 that causes
> >> unaligned access to trap there too.
> >
> > 1. CR0.AM must be set.
>
On Fri, 21 Nov 2014, Sam Hartman wrote:
> I thought there was a flag bit you could set on x86 that causes
> unaligned access to trap there too.
1. CR0.AM must be set.
2. Ask For The Pain!
i386:
__asm__("pushf\norl $0x4,(%esp)\npopf");
x86-64:
__asm__("pushf\norl $0x4,(%rsp)\npop
On Tue, 18 Nov 2014, Matthias Urlichs wrote:
> > trying to convert minidlna sysv init file to systemd, managed to have
> > a working unit file but failed to split the configuration mimicing
> > the ../default/minidlna content with the hability to make USER and
> > GROUP configurable
On Tue, 18 Nov 2014, Daniel Pocock wrote:
> How would people feel if dput was a wrapper around git?
dpkg --purge dput
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silic
On Mon, 17 Nov 2014, Russ Allbery wrote:
> Henrique de Moraes Holschuh writes:
> > I think I heard of someone using them *once*. It is very rare, AFAIK.
>
> > However, if there is one thing I learned the hard way, is that people
> > who use the advanced features don&#
On Mon, 17 Nov 2014, Anthony Towns wrote:
> On Mon, Nov 17, 2014 at 09:22:39AM -0800, Russ Allbery wrote:
> > Anthony Towns writes:
> > > BTW, it occured to me that it seems like a wart that update-rc.d doesn't
> > > respect policy-rc.d -- as it stands, policy-rc.d can prevent a service
> > > from
On Mon, 17 Nov 2014, Anthony Towns wrote:
> On Mon, Nov 17, 2014 at 02:38:04PM -0200, Henrique de Moraes Holschuh wrote:
> > On Mon, 17 Nov 2014, Anthony Towns wrote:
> > > If deb-systemd-* were to get merged in, it might be worth doing a name
> > > change at the s
On Mon, 17 Nov 2014, Anthony Towns wrote:
> If deb-systemd-* were to get merged in, it might be worth doing a name
> change at the same time, I guess. Changing either before jessie doesn't
> seem remotely plausible.
>
> I wonder if it would make sense to just merge it all into the "service"
> comm
On Mon, 17 Nov 2014, Anthony Towns wrote:
> Having a single tool that does the basic stuff admins and maintainers need
> independent of init system seems like the right approach to me. "*-rc.d"
> is a terrible name for such a tool, though :(
Err, yes. There were complains about the -rc.d prefix w
On Mon, 17 Nov 2014, Ron wrote:
> > Anything that doesn't store the full debian version (be it a git tag or a
> > filename) will have a colision risk. Consider a package that has versions
> > 1:2.3.5-1 and 5:2.3.5-1.
>
> Right, that was one of the first cases I mentioned. When you upload
> 5:2.3
On Sun, 16 Nov 2014, Nikolaus Rath wrote:
> "Ignoring block request by freeze, due to unblock request by adsb"
>
> I'm a little confused by that. What is adsb? Do we have some mechanism
finger a...@db.debian.org :-)
> that automatically unblocks packages? Or is this just the release team
> monit
On Sun, 16 Nov 2014, Ron wrote:
> On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote:
> > On Sat, 15 Nov 2014, Raphael Hertzog wrote:
> > > On Fri, 14 Nov 2014, Ian Jackson wrote:
> > > > > What exactly is your use case you feel this is
On Sat, 15 Nov 2014, Raphael Hertzog wrote:
> On Fri, 14 Nov 2014, Ian Jackson wrote:
> > > What exactly is your use case you feel this is essential for?
> >
> > I think this discussion is in danger of going round in circles.
> > I'm going to leave it here and let Raphael get on with it.
>
> I un
On Fri, 14 Nov 2014, Richard Hartmann wrote:
> On Fri, Nov 14, 2014 at 11:56 AM, Raphael Hertzog wrote:
> > On Thu, 13 Nov 2014, Tobias Frost wrote:
> >> One point came to my mind: NMUs
> >> Can we maybe add some words what would be best practice to handle NMUs?
> >
> > I think the current best pr
On Sat, 15 Nov 2014, Ron wrote:
> On Fri, Nov 14, 2014 at 03:39:05PM +, Ian Jackson wrote:
> > Ron writes ("Re: RFC: DEP-14: Recommended layout for Git packaging
> > repositories"):
> > > Why include the epoch in tags at all?
> >
> > Because we want to be able to tell not just which tag was w
On Wed, 12 Nov 2014, Daniel Pocock wrote:
> It is very sad to see that contributors sometimes feel that the only
> option for them is to resign.
>
> Would it be worthwhile giving people another option, for example,
> allowing a percentage of DDs to formally veto decisions? Would this be
> better
On Tue, 11 Nov 2014, Rogério Brito wrote:
> On 2014-11-11 15:30, Henrique de Moraes Holschuh wrote:
> > However, candidate packages due to reason (c) above really are a problem,
> > IMHO they shouldn't be in stable in the first place.
>
> Does this mean that I sho
On Wed, 12 Nov 2014, Raphael Hertzog wrote:
> On Tue, 11 Nov 2014, Henrique de Moraes Holschuh wrote:
> > In fact, I was quite non-amused by the initial versions of this idea, but
> > reading this latest version, I must say I *like* it. Well done! I am
> > especially h
On Tue, 11 Nov 2014, Iustin Pop wrote:
> > QUESTION: some people have argued to use debian/master as the latest
> > packaging targets sometimes sid and sometimes experimental. Should we
> > standardize on this? Or should we explicitly allow this as an alternative?
>
> Interesting. Assuming a
On Tue, 11 Nov 2014, Raphael Hertzog wrote:
> following the initial discussion we had in August
> (https://lists.debian.org/debian-devel/2014/08/thrd2.html#00499), I have
> written a first draft of the Debian Enhancement Proposal that I suggested.
> It's now online at http://dep.debian.net/deps/dep
On Tue, 11 Nov 2014, Luca Falavigna wrote:
> 2014-11-11 19:12 GMT+01:00 Andreas Tille :
> >> Depends: libc6 (>= 2.4), r-base-core (>= 3.1.2-2)
> >
> > Hmmm, this is what I missed. :-( I guess the only chance is to upload
> > to t-p-u, right?
>
> That could be an option. You have to coordinate wi
On Tue, 11 Nov 2014, Daniel Pocock wrote:
> On 11/11/14 18:30, Henrique de Moraes Holschuh wrote:
> > On Tue, 11 Nov 2014, Rebecca N. Palmer wrote:
> >> Possible candidates:
> >> a. Packages that work closely with hardware, where old versions
> >> don't
On Tue, 11 Nov 2014, Ian Jackson wrote:
> Simon McVittie writes ("Re: r-base-core upload to unstable does not respect
> freeze policy"):
> > On 11/11/14 15:55, Ian Jackson wrote:
> > > perhaps we should in general make more use of testing chroots for RC
> > > bugfixes to testing during the freeze.
On Tue, 11 Nov 2014, Rebecca N. Palmer wrote:
> Possible candidates:
> a. Packages that work closely with hardware, where old versions
> don't work with new hardware (example: beignet)
> b. Packages that implement fast-evolving file formats or network
> protocols, where you need the same version as
On Wed, 29 Oct 2014, Jonas Smedegaard wrote:
> Speaking of which: Is it Policy or just habit to use GCC over Clang?
gcc still generates better machine code than clang in the *general* case for
C source (I don't know about the rest). There is no policy to use gcc: if
your program builds better usi
On Sun, 26 Oct 2014, Jakub Wilk wrote:
> * Henrique de Moraes Holschuh , 2014-10-26, 10:57:
> >"rmdir >/etc/foo/bar/ >/dev/null 2>&1 || true" is always a safe
> >operation...
>
> Instead of ignoring (and hiding) all errors, it's better use
>
On Sun, 26 Oct 2014, Pau Garcia i Quiles wrote:
> "Do you want to enable an external repository which will provide you with
> the latest version of Wt?
That behaviour is discouraged in Debian.
We don't mind if you offer the PPAs, but the official packages should
*NEVER* enable PPAs or offer to do
On Sun, 26 Oct 2014, Santiago Vila wrote:
> > So, dpkg-maintscripthelper seems to do "Removing obsolete conffile"
> > after dpkg tries to delete old directories, so dpkg fails.
> >
> > I'd be surprised if I were the first to encounter this problem: what is
> > the appropriate and clean way to get
On Wed, 22 Oct 2014, Thorsten Glaser wrote:
> Jelmer Vernooij dixit:
> >Samba is unlikely to add such an exception.
>
> So just make OpenSSL a system library finally.
It has always been a system library in Debian.
The problem is that Debian is the operating system distributing the system
librari
On Mon, 13 Oct 2014, Miles Fidelman wrote:
> Henrique de Moraes Holschuh wrote:
> >On Mon, 13 Oct 2014, Matthias Urlichs wrote:
> >>In any case, users _do_ have a say. They can force their systems to remain
> >>on sys5 init, or switch to a different distro if that shoul
On Mon, 13 Oct 2014, Matthias Urlichs wrote:
> In any case, users _do_ have a say. They can force their systems to remain
> on sys5 init, or switch to a different distro if that should also turn out
Which, I should add, is something we measure if the user installs
popularity-contest and opts-in to
On Fri, 10 Oct 2014, Don Armstrong wrote:
> We probably should be just using sane security to score the messages
> instead of outright rejecting them... but the war on spam is hard.
Speaking as someone that was the postmaster of several sites that used the
Sanesecurity database for years. There i
On Wed, 08 Oct 2014, Paul Gevers wrote:
> Thanks for the careful response. And no, as mentioned above, I didn't
> mean to use dpkg-statoverride itself. dbconfig-common uses debconf and
> ufc to manage the configuration files. However, dbconfig-common checks
> with dpkg-statoverride if the configura
On Tue, 07 Oct 2014, Paul Gevers wrote:
> I am trying to come up with a patch against dpkg-statoverride that sets
> the ownership and permissions upon creation, but not upon updates.
This really doesn't look like a good idea. In fact, it may well introduce
very confusing and likely dangerous beha
On Fri, 03 Oct 2014, Russell Stuart wrote:
> On Fri, 2014-10-03 at 00:04 +, brian m. carlson wrote:
> > The shell you're describing is posh. It implements exactly those
> > features, and nothing more.
>
> You've got me to look at posh. Thanks for that.
>
> So we do have a shell that develop
On Tue, 30 Sep 2014, Thorsten Glaser wrote:
> On Fri, 26 Sep 2014, Matthias Urlichs wrote:
> > In any case, adding "-p" to any #!/bin/bash shebang line looks like a very
> > good idea. Shall we add a Lintian check for this?
>
> ***ABSOLUTELY NOT***
>
> The -p option is for the shell to *not* drop
On Mon, 29 Sep 2014, Matthias Urlichs wrote:
> > So, can we get now some alternative proposals that address the fact that
> > some mirrors need >48H validity, and many leaf mirrors really want at least
> > a week?
>
> How about "Security updates are published on security.d.o, so _that_
> archive's
On Mon, 29 Sep 2014, Christoph Anton Mitterer wrote:
> Now to deal with your concern of larger outages:
> 2) Just because there are no valid [In]Release* files, it doesn't mean
> that those mirrors and their repositories can't be used any longer. The
> data is still there as it was before.
> An app
On Thu, 25 Sep 2014, Simon McVittie wrote:
> Approach 1, which is (IMO) better when the changes you are making in
> experimental are truly experimental, like enabling features or patches
> whose medium-term future you're not sure about:
>
> 2.2.5-5+exp1, ... or -6~exp1, ... or whatever to experime
On Thu, 25 Sep 2014, Riku Voipio wrote:
> On Wed, Sep 24, 2014 at 03:18:02PM -0300, Henrique de Moraes Holschuh wrote:
> > OTOH, using -z9 on datasets smaller than the -z8 dictionary size *is* a
> > waste of memory (I don't know about cpu time, and xz(1) doesn't say an
On Thu, 25 Sep 2014, Thomas Goirand wrote:
> On 09/02/2014 09:39 PM, Henrique de Moraes Holschuh wrote:
> > For -z9, it is as bad as ~670MiB to
> > compress, and ~65MiB to decompress.
>
> I'd say this really depends on what you do. For what I do (eg: OpenStack
> pa
On Tue, 16 Sep 2014, Andrey Rahmatullin wrote:
> On Tue, Sep 16, 2014 at 12:02:24PM +0200, Matthias Urlichs wrote:
> > You might want to pop up a preinst debconf notice which tells the admin
> > that the package will not run here (with an option to fail the install
> > if it's an honest mistake).
>
On Wed, 03 Sep 2014, Ritesh Raj Sarraf wrote:
> >My inclination is to ship both, the systemd service files and the
> >init scripts, in their current form along with whatever
> >limitations each may have, and let the user choose.
>
> I did not get any comment on this. How are others doing similar
>
On Tue, 02 Sep 2014, Jonathan Dowland wrote:
> On Tue, Sep 02, 2014 at 01:45:30PM +0200, Adam Borowski wrote:
> > For any standardish font, taking any extra memory is a no-no. You might be
> > running in a chroot on a 256MB RAM phone, etc.
> >
> > On the other hand, for a 400MB game, not using -z
On Tue, 26 Aug 2014, Henrique de Moraes Holschuh wrote:
> I'd like to know whether the kernel microcode update is working well on some
> of the older Intel 32-bit processors or not. These computers were sold
> between years 2000 and 2010.
>
> This information will be used to
On Thu, 28 Aug 2014, Andrea Bolognani wrote:
> On Tue, Aug 26, 2014 at 03:49:06PM -0300, Henrique de Moraes Holschuh wrote:
> > I'd like to know whether the kernel microcode update is working well on some
> > of the older Intel 32-bit processors or not. These computers were so
I am the maintainer of the intel-microcode and iucode-tool packages, used to
update the microcode[1] on Intel system processors (CPU chip).
I'd like to know whether the kernel microcode update is working well on some
of the older Intel 32-bit processors or not. These computers were sold
between y
On Tue, 19 Aug 2014, Hector Oron wrote:
> 2014-08-15 16:04 GMT+02:00 Ondřej Surý :
> > I have encountered a situation where the FTBFS bug was caused
> > by segfault in other package. This has forced me to split opendnssec-doc
> > to arch:all package (which was good thing anyway), so there are cases
On Tue, 19 Aug 2014, Lars Wirzenius wrote:
> On Mon, Aug 18, 2014 at 07:28:51PM -0400, Barry Warsaw wrote:
> > Also, it makes me somewhat uncomfortable to assume that a git tag in the
> > upstream repo will always be equivalent to their released tarball. In fact,
> > it's often not, as is the case
On Sun, 17 Aug 2014, Marc Haber wrote:
> Please. The attitute of requiring Debian maintainers to modify
> upstream software instead of having simple two-line extension to an
> init script is really unfriendly. Why do only systemd friends keep
> recommending this?
Using my sysvinit hat, I've always
On Sun, 17 Aug 2014, Thomas Goirand wrote:
> > Obviously, when upstream are already doing everything correctly, creating
> > the upstream/ tag should not become some administrative chore but
> > it could be done automatically as part of a some "gbp upstream-merge
> > " command for example.
>
> Ah,
On Mon, 18 Aug 2014, Don Armstrong wrote:
> On Mon, 18 Aug 2014, Thorsten Glaser wrote:
> > This does not work in Debian: you always need the .orig.tar.* file,
> > at least for the upload, for non-native packages.
>
> You need it from somewhere, but the whole point of pristine-tar is that
> you ca
On Sun, 17 Aug 2014, Thomas Goirand wrote:
> On 08/17/2014 03:52 AM, Raphael Hertzog wrote:
> > On Fri, 15 Aug 2014, Henrique de Moraes Holschuh wrote:
> >>> - the above layout is for the traditional case of non-native packages,
> >>> what would be the layou
On Fri, 15 Aug 2014, Steve Langasek wrote:
> The alternative is handwaving and ignoring the fact that your package
> repository is not a complete representation of your package as it exists in
> the archive.
What's wrong with storing the upstream tarballs themselves on a separate
branch, if you're
On Fri, 15 Aug 2014, Michael Biebl wrote:
> Am 15.08.2014 17:47, schrieb Gerrit Pape:
> > Package: rsyslog
> > Version: 8.2.2-3
> > Severity: serious
> > Justification: Policy 2.5
> >
> > Hi, the current rsyslog package version in testing is priority important
> > and depends on packages with prio
On Fri, 15 Aug 2014, Christian Kastner wrote:
> On 2014-08-15 16:16, Raphael Hertzog wrote:
> > - pkg/
> > (note: git-buildpackage uses debian/ but I find this confusing
> > as we then also have the "debian/" prefix for ubuntu or kali uploads, we
> > don't need the vendor prefix as the usua
On Fri, 15 Aug 2014, Raphael Hertzog wrote:
> - how do we tag the package releases?
>
> - pkg/
> (note: git-buildpackage uses debian/ but I find this confusing
> - shall we standardize the "pristine-tar" branch?
IMHO it should be reserved for pristine-tar usage (as in "don't use it for
somet
On Fri, 15 Aug 2014, Ondřej Surý wrote:
> On Fri, Aug 15, 2014, at 15:37, Henrique de Moraes Holschuh wrote:
> > And any package that cannot build arch:all on a released arch for which
> > it produces binary packages potentially has a FTBFS bug, anyway, which
> > can be repor
On Fri, 15 Aug 2014, Raphael Hertzog wrote:
> On Fri, 15 Aug 2014, Hector Oron wrote:
> > Even building arch:all packages in one architecture might solve the
> > issue, I do not like that approach, as it holds other arches from
> > building until that "primary" arch has built arch:all packages.
>
On Wed, 13 Aug 2014, Brian May wrote:
> * Package name: cryptography
...
> I imagine the binary package will be called python{,3}-cryptography.
> Haven't got to this step yet.
Wouldn't it be better to also have the source package name in the python-
namespace? Its using a dictionary word for
On Sat, 09 Aug 2014, Henrique de Moraes Holschuh wrote:
> > This is not really relevant. What is relevant, however, is that nobody is
> > disputing that libjpeg8 produce higher quality images than libjpeg62 when
> > decompressing standard JPEG images.
>
> If this is t
On Sat, 09 Aug 2014, Bill Allombert wrote:
> > 3. libjpeg8 adds new features to the JPEG image format. These have
> > however been rejected from the ISO standard, and their
> > contributions to image quality and compression appear to be widely
> > disputed.
>
> This is not really rel
On Sat, 02 Aug 2014, Josh Triplett wrote:
> How easily could you teach syslog-nagios-bridge to listen on a UNIX
> domain socket, instead of or in addition to a TCP socket? You could
> then have it listen on /run/syslog-nagios-bridge by default, and have
> rsyslog automatically forward messages the
On Mon, 28 Jul 2014, Norbert Preining wrote:
> On Sun, 27 Jul 2014, Reinhard Tartler wrote:
> > In [1], Moritz from the security team clearly stated that he is more
> > than uncomfortable with having more than one copy of libavcodec in
> > debian/testing. In consequence this means that any package
On Mon, 14 Jul 2014, Jakub Wilk wrote:
> * Peter Palfrader , 2014-07-14, 20:25:
> >>The basic idea is that it's much harder to come up with a
> >>simultaneoush hash collision with both SHA-1 and SHA-2 than
> >>breaking either of them independently.
> >
> >ISTR reading papers that put this "much har
On Mon, 14 Jul 2014, Nathan Schulte wrote:
> "ASCII hex" encodes 4 bits as 8 (or 7. but really 8.), as each ASCII
> character is a nibble of the digest; that's a 100% increase (factor
> of 2) over the bare digest (or a "raw mapping" of 8 bits of digest
> to an 8 bit character set).
The figures giv
101 - 200 of 1206 matches
Mail list logo
