UNIQUE LOGO ANIMATIONS
Hello, We can design and animate your company logo. Animatic studio is a leading world company specialized in logo designing and logo animating! Our quality is more than high! You can see the examples from our website below. www.animatic.rs Price list: Logo Design $150 USD 2D Logo Animation start from $250 USD 3D Logo Animation start from $400 USD We hope that we will work soon. Regards Mr. Imran Javid Sales Manager at Animatic Studio E-mail: salesmana...@animatic.rs Skype: animaticsales Phone: +381(64)4308696 www.animatic.rs -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150724105322.16482y78yoqb3...@webmail.animatic.rs
Re: Bug#741573: #741573: Menu Policy and Consensus
Charles == Charles Plessy ple...@debian.org writes: Charles I made efforts to keep the wording mild, but I think that Charles it was an error. From your attiude as the lead person behind the Debian Menu, it is clear that Charles it has no future. For one decade, you have taken no Charles leadership to build this future. As a consequence, I think Charles that the next step is to plan its replacement and Charles deprecation. Maybe the TC will come to this conclusion. That seems very unlikely to me. Diversity is an important part of Debian. I think it is likely that the TC is going to value the Debian Menu as long as Bill or someone else is going to work on it. I would expect us to value the menu enough to enable those who want to contribute to it to do so. I think that's consistent with the consensus proposal that you asked us to consider in this bug. -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/014ec023d831-235170e7-57c9-4cb9-b546-77c1ffb10231-000...@email.amazonses.com
Bug#793493: debian-policy: Update dpkg-architecture flags information
Package: debian-policy Version: 3.9.7.0 Severity: wishlist Tags: patch Hi! Here's a partial update to match the current dpkg-architecture output. I've left the MULTIARCH variable alone, because that's supposedly tracked on another bug. The wording might be a bit unnatural, review by a native speaker advised. :) Thanks, Guillem From 0bc030c417adfa7ca50944c918101dd9ce62bebb Mon Sep 17 00:00:00 2001 From: Guillem Jover guil...@debian.org Date: Fri, 24 Jul 2015 17:17:58 +0200 Subject: [PATCH 1/2] Update information about DEB_TARGET_* variables These are used to support building cross-compilers. Introduced in dpkg 1.17.14. --- policy.sgml | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/policy.sgml b/policy.sgml index 404dc73..72a2505 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2175,9 +2175,16 @@ zope. the architecture on which filedebian/rules/file is run and the package build is performed. The host architecture is the architecture on which the resulting package will be installed - and run. These are normally the same, but may be different in + and run. The target architecture is the architecture of the + packages that the compiler currently being built will generate. + These are normally the same, but may be different in the case of cross-compilation (building packages for one - architecture on machines of a different architecture). + architecture on machines of a different architecture), building a + cross-compiler (a compiler package that will generate objects for + one architecture, built on a machine of a different architecture) + or a Canadian cross-compiler (a compiler that will generate + objects for one architecture, built on a machine of a different + architecture, that will run on yet a different architecture). /p p @@ -2205,8 +2212,9 @@ zope. ttDEB_*_GNU_TYPE/tt) /list where tt*/tt is either ttBUILD/tt for specification of - the build architecture or ttHOST/tt for specification of the - host architecture. + the build architecture, ttHOST/tt for specification of the + host architecture or ttTARGET/tt for specification of the + target architecture. /p p -- 2.5.0.rc2.392.g76e840b From 70aaad841a5067db2737ea658532eb92d9376888 Mon Sep 17 00:00:00 2001 From: Guillem Jover guil...@debian.org Date: Fri, 24 Jul 2015 17:19:06 +0200 Subject: [PATCH 2/2] Update information about DEB_*_ARCH_* variables Mention DEB_*_ARCH_BITS and DEB_*_ARCH_ENDIAN. Introduced in dpkg 1.15.4. --- policy.sgml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/policy.sgml b/policy.sgml index 72a2505..b7f0464 100644 --- a/policy.sgml +++ b/policy.sgml @@ -2197,6 +2197,12 @@ zope. ttDEB_*_ARCH_CPU/tt (the Debian CPU name) /item item + ttDEB_*_ARCH_BITS/tt (the Debian CPU pointer size in bits) + /item + item + ttDEB_*_ARCH_ENDIAN/tt (the Debian CPU endianness) + /item + item ttDEB_*_ARCH_OS/tt (the Debian System name) /item item -- 2.5.0.rc2.392.g76e840b
Respect
Folks, we've decided as a communiity that we will choose to respect each other in our communications. Every participant is deserving of your respect, regardless of whether you agree with them. The community is deserving of respectful communication even when you feel that you have not been respected. That is, bad behavior on the part of others does not justify bad behavior on your part. I'd ask us all to take a breath and remember to treat each other with respect If you feel that you've not been respected, you have a number of options. You can talk to people directly asking them for respect. You can contact listmas...@debian.org, antiharassm...@debian.org, or lea...@debian.org and ask for help. I understand emotions are high, but I hope that we each can choose to live up to the highest level of discussion we are able regardless of what others do. pgplO5K7ePhV4.pgp Description: PGP signature
Bug#792853: debian-policy: please disallow colons in upstream_version
On Sun, Jul 19, 2015 at 13:48:14 +0200, Jakub Wilk wrote: Package: debian-policy Severity: wishlist Policy §5.6.12 reads: “The upstream_version may contain only alphanumerics and the characters ‘.’ ‘+’ ‘-’ ‘:’ ‘~’ (full stop, plus, hyphen, colon, tilde) and should start with a digit. […] if there is no epoch then colons are not allowed.” But in practice: 1) There's been never a package with a colon in upstream_version in the archive. 2) A colon in upstream_version implies a colon in the filename. Some software might not tolerate such filenames; see bug #645895 for discussion. 3) dpkg in unstable won't even let you build a package with such version: $ head -n1 debian/changelog adequate (1:1:1) UNRELEASED; urgency=low $ dpkg-buildpackage -S […] dpkg-genchanges -S ../adequate_1:1_source.changes dpkg-genchanges: error: invalid filename adequate_1:1.dsc dpkg-buildpackage: error: dpkg-genchanges gave error exit status 255 As far as I can tell, dak would reject such a filename, too (the commit message doesn't seem to consider colons as part of upstream_version at all): http://anonscm.debian.org/cgit/mirror/dak.git/tree/daklib/regexes.py#n134 http://anonscm.debian.org/cgit/mirror/dak.git/commit/?id=e86a4800 Cheers, Julien signature.asc Description: Digital signature
Re: Bug#741573: #741573: Menu Policy and Consensus
Sam Hartman hartm...@debian.org wrote: That seems very unlikely to me. Diversity is an important part of Debian. I think it is likely that the TC is going to value the Debian Menu as long as Bill or someone else is going to work on it. I would expect us to value the menu enough to enable those who want to contribute to it to do so. Given the state menu is in, reading this is… flabbergasting, to say the least. I would answer tons of things, but fortunately they have already been put together concisely: http://islinuxaboutchoice.com/ I think that's consistent with the consensus proposal that you asked us to consider in this bug. The consensus proposal was, in order to preserve some bits of Bill’s ego, to let menu die slowly by stopping to require mandatory entries for a useless menu system that only a handful of obscure window managers are still able to display. Now that Bill has made very clear, by completely giving in to ridicule, that his ego should not be a problem, Charles is merely proposing to accelerate that process and avoid pain for everyone. -- Joss -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1437747652.13194.42.ca...@dsp0698014.postes.calibre.edf.fr
Bug#793499: debian-policy: The Installed-Size algorithm is out-of-date
Package: debian-policy Version: 3.9.7.0 Severity: wishlist Hi! As discussed in the debian-policy list, the Installed-Size algorithm as implemented in dpkg-gencontrol changed due to #650077. So the current wording is out-of-sync. Please see the thread starting at https://lists.debian.org/debian-policy/2011/11/msg00079.html, with the current implementation https://lists.debian.org/debian-policy/2015/01/msg00044.html. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150724160441.gb7...@gaara.hadrons.org
Bug#792853: debian-policy: please disallow colons in upstream_version
Hi! On Sun, 2015-07-19 at 20:25:04 -0700, Russ Allbery wrote: Guillem Jover guil...@debian.org writes: So, in principle 2) and 3) are mostly problems in dpkg, 1) might be a quite good indication that upstreams do not usually do this, and 4) a very strong deterrent for them to do so. I'm ambivalent on disallowing this in Debian, and even if policy ends up disallowing it might still make sense to allow it in dpkg in case someone outside Debian is using such thing (although I'm having a bit of a hard time seeing this being used in practice). I feel like simplicity in our version numbering scheme is best. It's clear that no one is currently using this, and this message is the first time I recall it even coming up. That implies that we're not losing much (if anything) by not supporting this, even though we claimed it was supported. The simplest approach for Debian seems to be to just forbid colons in upstream version numbers. This also simplifies parsing mildly. Right, makes sense. Although I wouldn't like for that regression in dpkg to be used as a “fait accompli” argument. (Obviously, dpkg is free to be more generous, although it's convenient when dpkg aligns with Debian Policy in a way that doesn't require writing a separate Lintian rule.) So I've decided I'll merge the fix for now, which can always be reverted if Debian Policy forbids its usage, but in that case I'd probably implement a proper staged deprecation process, with warnings and all, to catch the possible but improbable external users. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150724163805.ga8...@gaara.hadrons.org
