debian-archive-keyring installing ubuntu keys?
I have a project that is building in the travis-ci.org environment (based on Ubuntu) I added the following to .travis.yml to try and make it use packages from sid: before_install: - sudo apt-get update -qq - sudo apt-get install -qq debian-archive-keyring - sudo add-apt-repository -y "deb http://http.debian.net/debian/ sid main" - sudo apt-get update -qq - sudo apt-get install -qq gperf libasio-dev libboost-dev libc-ares-dev libdb++-dev The log shows the following output: Unpacking debian-archive-keyring (from .../debian-archive-keyring_2010.08.28_all.deb) ... Setting up debian-archive-keyring (2010.08.28) ... gpg: key 437D05B5: "Ubuntu Archive Automatic Signing Key " not changed gpg: key FBB75451: "Ubuntu CD Image Automatic Signing Key " not changed gpg: Total number processed: 2 gpg: unchanged: 2 ... $ sudo apt-get update -qq W: GPG error: http://http.debian.net sid InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 8B48AD6246925553 ... $ sudo apt-get install -qq gperf libasio-dev libboost-dev libc-ares-dev libdb++-dev libpopt-dev libssl-dev .. WARNING: The following packages cannot be authenticated! locales libnih-dbus1 libnih1 libc-dev-bin libc6-dev libc6 libdb5.3 perl . . . Is this simply because I'm trying to use packages from sid? Or is this "debian-archive-keyring" package at fault? My understanding is that because the package has debian in the name, it will give me Debian project keys. Build log: https://travis-ci.org/resiprocate/resiprocate/jobs/21572385 -- 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/53329253.4090...@pocock.com.au
Re: debian-archive-keyring installing ubuntu keys?
On 2014-03-26 8:39, Daniel Pocock wrote: I have a project that is building in the travis-ci.org environment (based on Ubuntu) [...] Unpacking debian-archive-keyring (from .../debian-archive-keyring_2010.08.28_all.deb) ... Setting up debian-archive-keyring (2010.08.28) ... That package is older than the version in squeeze (i.e. oldstable). However, even fetching the package from Ubuntu trivially shows that it does not contain any non-Debian keys: $ wget http://mirrors.kernel.org/ubuntu/pool/universe/d/debian-archive-keyring/debian-archive-keyring_2010.08.28_all.deb $ mkdir debtmp $ dpkg-deb -x debian-archive-keyring_2010.08.28_all.deb debtmp $ gpg --no-default-keyring --keyring debtmp/usr/share/keyrings/debian-archive-keyring.gpg --list-keys debtmp/usr/share/keyrings/debian-archive-keyring.gpg pub 1024D/F42584E6 2008-04-06 [expired: 2012-05-15] uid Lenny Stable Release Key pub 4096R/55BE302B 2009-01-27 [expired: 2012-12-31] uid Debian Archive Automatic Signing Key (5.0/lenny) pub 2048R/6D849617 2009-01-24 [expired: 2013-01-23] uid Debian-Volatile Archive Automatic Signing Key (5.0/lenny) pub 4096R/B98321F9 2010-08-07 [expires: 2017-08-05] uid Squeeze Stable Release Key pub 4096R/473041FA 2010-08-27 [expires: 2018-03-05] uid Debian Archive Automatic Signing Key (6.0/squeeze) $ " not changed gpg: key FBB75451: "Ubuntu CD Image Automatic Signing Key " not changed gpg: Total number processed: 2 gpg: unchanged: 2 This suggests that you've got ubuntu-keyring installed in the environment. You'll notice that the messages all say "not changed". There are no new keys being added at this point. What's happening is this: if which apt-key > /dev/null; then apt-key update fi [from debian-archive-keyring's postinst] [...] Is this simply because I'm trying to use packages from sid? Or is this "debian-archive-keyring" package at fault? As far as I can tell, neither of these is the case. If you don't want your environment to contain Ubuntu keys, don't install ubuntu-keyring in it. I can't see how to easily tell from your setup exactly what's installed in the environment before your job started, or I'd supply a link. My understanding is that because the package has debian in the name, it will give me Debian project keys. It does. Regards, Adam -- 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/fb6af1ae9f456894d43ea389b01ab...@mail.adsl.funky-badger.org
Re: debian-archive-keyring installing ubuntu keys?
On 26/03/14 10:03, Adam D. Barratt wrote: > On 2014-03-26 8:39, Daniel Pocock wrote: >> I have a project that is building in the travis-ci.org environment >> (based on Ubuntu) > [...] >> Unpacking debian-archive-keyring (from >> .../debian-archive-keyring_2010.08.28_all.deb) ... >> Setting up debian-archive-keyring (2010.08.28) ... > > That package is older than the version in squeeze (i.e. oldstable). > > However, even fetching the package from Ubuntu trivially shows that it > does not contain any non-Debian keys: > > $ wget > http://mirrors.kernel.org/ubuntu/pool/universe/d/debian-archive-keyring/debian-archive-keyring_2010.08.28_all.deb > $ mkdir debtmp > $ dpkg-deb -x debian-archive-keyring_2010.08.28_all.deb debtmp > $ gpg --no-default-keyring --keyring > debtmp/usr/share/keyrings/debian-archive-keyring.gpg --list-keys > > debtmp/usr/share/keyrings/debian-archive-keyring.gpg > > pub 1024D/F42584E6 2008-04-06 [expired: 2012-05-15] > uid Lenny Stable Release Key > > > pub 4096R/55BE302B 2009-01-27 [expired: 2012-12-31] > uid Debian Archive Automatic Signing Key (5.0/lenny) > > > pub 2048R/6D849617 2009-01-24 [expired: 2013-01-23] > uid Debian-Volatile Archive Automatic Signing Key > (5.0/lenny) > > pub 4096R/B98321F9 2010-08-07 [expires: 2017-08-05] > uid Squeeze Stable Release Key > > > pub 4096R/473041FA 2010-08-27 [expires: 2018-03-05] > uid Debian Archive Automatic Signing Key > (6.0/squeeze) > > $ > >> " not changed >> gpg: key FBB75451: "Ubuntu CD Image Automatic Signing Key >> " not changed >> gpg: Total number processed: 2 >> gpg: unchanged: 2 > > This suggests that you've got ubuntu-keyring installed in the > environment. > > You'll notice that the messages all say "not changed". There are no > new keys being added at this point. What's happening is this: > > if which apt-key > /dev/null; then > apt-key update > fi > Maybe that postinst script needs to echo "Summary of which keys are already on your system:" so it is clear the output does not relate to the contents of the package. > [from debian-archive-keyring's postinst] > > [...] >> Is this simply because I'm trying to use packages from sid? Or is this >> "debian-archive-keyring" package at fault? > > As far as I can tell, neither of these is the case. If you don't want > your environment to contain Ubuntu keys, don't install ubuntu-keyring > in it. > In this case, I don't mind if the environment has Ubuntu keys, I just wanted to make sure I could get the Debian keys as well > I can't see how to easily tell from your setup exactly what's > installed in the environment before your job started, or I'd supply a > link. I believe each travis-ci build environment starts out running the last stable Ubuntu LTS (12.04) I've just tweaked the build script some more, I tried: a) dist-upgrade to saucy b) install debian-archive-keyring from saucy c) dist-upgrade to sid but that fails too as it does not appear to be a valid upgrade path. I'll try the same thing but s/saucy/trusty before_install: - sudo add-apt-repository -y "deb http://archive.ubuntu.com/ubuntu/ saucy main universe" - sudo apt-get update -qq - sudo apt-get dist-upgrade -qq - sudo add-apt-repository -y "deb http://http.debian.net/debian/ sid main" - sudo apt-get update -qq - sudo apt-get install -qq --force-yes debian-archive-keyring - sudo apt-get update -qq - sudo apt-get dist-upgrade -qq - sudo apt-get install -qq gperf libasio-dev libboost-dev libc-ares-dev libdb++-dev libpopt-dev \ libssl-dev perl libmysqlclient-dev libfreeradius-client-dev libcppunit-dev autotools-dev \ libpcre3-dev libxerces-c-dev curl libcajun-dev python-cxx-dev libsipxtapi-dev libsrtp-dev Latest build log https://travis-ci.org/resiprocate/resiprocate/jobs/21574148 -- 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/53329a8e.9080...@pocock.com.au
Re: debian-archive-keyring installing ubuntu keys?
On 2014-03-26 9:14, Daniel Pocock wrote: On 26/03/14 10:03, Adam D. Barratt wrote: On 2014-03-26 8:39, Daniel Pocock wrote: " not changed gpg: key FBB75451: "Ubuntu CD Image Automatic Signing Key " not changed gpg: Total number processed: 2 gpg: unchanged: 2 This suggests that you've got ubuntu-keyring installed in the environment. You'll notice that the messages all say "not changed". There are no new keys being added at this point. What's happening is this: if which apt-key > /dev/null; then apt-key update fi Maybe that postinst script needs to echo "Summary of which keys are already on your system:" so it is clear the output does not relate to the contents of the package. It's somewhat academic now, as the package in wheezy and later ships files in /etc/apt/trusted.gpg.d directly and no longer calls "apt-key update". Regards, Adam -- 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/1c4b1358b7a8ac6c0f6e3bba90cee...@mail.adsl.funky-badger.org
Re: jquery debate with upstream
On 2014-03-26 02:49, Paul Wise wrote: On Wed, Mar 26, 2014 at 6:16 AM, Philipp Kern wrote: To be honest I'd rather like to see a "ruling" which is codified in a policy than random guesswork we do on -devel from observing FTP masters' actions. This is not Mao. Figuring out what the source is and where it is can be hard, even for code. For example, xserver-xorg-video-nv was in Debian for 3 months before #383465 was filed and the code was in xserver-xfree86 for a couple of releases before that. I don't think this is similar to what we are discussing. Kind regards Philipp Kern -- 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/fcc97873e9b61f91ad79523ff5de4...@hub.kern.lc
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 03/25/2014 12:42 AM, Kevin Toppins wrote: > Sorry for the intrusion into your world, but this *needed* to be said, > and needed to be said on *this* specific list. Not correct. We didn't need another iteration of such a post. > -> the *future* of linux actually *does* depend on what -> you <- *do* here Correct. Which doesn't include reading or writing such a message. If you want thing to move on, stop posting useless messages, and start working on alternatives. For example, helping adding more features to OpenRC would certainly help a way more than this post. Writing an independent, init system agnostic, logind API compatible daemon would be another good thing to do. Thomas Goirand (zigo) -- 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/5332ae91.9070...@debian.org
Re: Bug#741930: reportbug: add current init system information
Hi, Michael Biebl: > I do think it might be useful information, at least during the > transition period. We can always revisit this decision in jessie+X, if > by that time the vast majority is running systemd. > We'd still want that information, if/when the current init is *not* systemd. Likewise, we might want to suppress the "current shell" line if it's dash. Personally, though, I tend to disregard that whole block of lines as mostly-irrelevant for the vast majority of bug reports. If there's two more lines of useless-to-me text in there, who cares? -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: dist-upgrade strangeness: dependencies not deconfigured
Hi! On Tue, 2014-03-25 at 22:38:45 -0700, Steve Langasek wrote: > What you're showing here is a snapshot at some point in the middle of an > upgrade, when texlive-common has been removed (because the package no longer > exists, and the new texlive-base conflicts with it) and texlive-base has not > yet been upgraded. It's legitimate to do this during an upgrade; in fact, > normally the very next step is for apt to unpack the new version of > texlive-base which had declared the Conflicts: with texlive-common. But > something else stopped apt before it got that far. Actually I'd say it's almost never legitimate for a frontend to do that. > For the record, the removal of texlive-common without the deconfiguring of > texlive-base is because apt will pass --force-depends to dpkg. It does this > because in various scenarios, dpkg when left to its own devices can find > itself in a catch-22 on dist-upgrades. So apt deliberately lets the > dependencies be broken, with the expectation that it can fix them up again > afterwards. Which is wrong, no well-behaved frontend should need to use any force option at all. The reason some frontends do is because they do not tell dpkg exactly what kind of transaction they want to perform, so dpkg is missing that information and migth find itself unable to proceed. The correct way to do that would be by telling which packages the frontend wants to be purged or removed via selections before installing others so that dpkg can decide to remove them when needed or convenient. The much maligned dselect frontend has managed w/o any force option, and unfortunately only somwhat recently I reasinged bug reports to apt (#579790) and cupt (#575786 which I need to follow up on) to request they switch to use selections too. Thanks, Guillem -- 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/20140326142000.ga5...@gaara.hadrons.org
Bug#742709: ITP: octomap -- An Efficient Probabilistic 3D Mapping Framework Based on Octrees
Package: wnpp Severity: wishlist Owner: "Leopold Palomo-Avellaneda" * Package name: octomap Version : 1.6.5 Upstream Author : Armin Hornung, Kai M. Wurm, Maren Bennewitz, Cyrill Stachniss and Wolfram Burgard * URL : http://octomap.github.io/ * License : GPL-2 and BSD-3-Clause Programming Lang: C++ Description : An Efficient Probabilistic 3D Mapping Framework Based on Octrees The OctoMap library implements a 3D occupancy grid mapping approach, providing data structures and mapping algorithms in C++ particularly suited for robotics. The map implementation is based on an octree and is designed to meet the following requirements: * Full 3D model. The map is able to model arbitrary environments without prior assumptions about it. The representation models occupied areas as well as free space. Unknown areas of the environment are implicitly encoded in the map. While the distinction between free and occupied space is essential for safe robot navigation, information about unknown areas is important, e.g., for autonomous exploration of an environment. * Updatable. It is possible to add new information or sensor readings at any time. Modeling and updating is done in a probabilistic fashion. This accounts for sensor noise or measurements which result from dynamic changes in the environment, e.g., because of dynamic objects. Furthermore, multiple robots are able to contribute to the same map and a previously recorded map is extendable when new areas are explored. * Flexible. The extent of the map does not have to be known in advance. Instead, the map is dynamically expanded as needed. The map is multi-resolution so that, for instance, a high-level planner is able to use a coarse map, while a local planner may operate using a fine resolution. This also allows for efficient visualizations which scale from coarse overviews to detailed close-up views. * Compact. The map is stored efficiently, both in memory and on disk. It is possible to generate compressed files for later usage or convenient exchange between robots even under bandwidth constraints. -- 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/20140326150347.11817.51866.report...@soho.upc.es
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On Wed, Mar 26, 2014 at 3:40 AM, Thomas Goirand wrote: > On 03/25/2014 12:42 AM, Kevin Toppins wrote: > Writing an independent, init system agnostic, logind API compatible > daemon would be another good thing to do. > That is pretty much impossible, according to the developers of the logind API and its single implementation. Perhaps a subset of the logind API for use by desktop environments / compositors would be more useful in this init and OS portability predicament. I think Matthias Clasen, a GNOME developer, actually recently expressed interest in this from a portable window manager and compositor's perspective.
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 26 March 2014 05:40, Thomas Goirand wrote: [...] > If you want thing to move on, stop posting useless messages, and start > working on alternatives. For example, helping adding more features to > OpenRC would certainly help a way more than this post. I am going to have to respectfully disagree with you on my post being useless. First off, let's realize that we have more than one problem here. The actual implementation work that you indicate should be done is a valid point. We are both in agreement there. However, there exists an even bigger problem to be tackled. You can come up with all the solutions you want, but until it is *widely understood* that your solutions are *needed*, people tend to ignore and dismiss you. You can clearly see that happening in the responses I got back in Nov 2012. You first have to help people *understand* the problem and given how all the other topics on systemd being a failure *still didn't stop* debian's progress with using it I decided a very different perspective needed to be introduced. And I had to wait a while for things to get bad enough for people to see some validity in what I am saying. And while *you* might understand systemd is a problem, it is *objectively evident* that most do not, given the recent momentum to further adopt systemd by the linux community at large. My post is an analysis of systemd from an engineer's point of view. And systemd *violates* every engineering principle I spent years in college to learn. The biggest problem is awareness and that is the primary purpose of my post. And having it discussed in closed or private circles does not help mass awareness. It needs to be out in the open where everyone can read it. But it will have the most traction here. Hence why debian-devel was the primary target all along. -Kev -- 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/CADkoAxhLo5fmJHEukhct2WB1ATH6a4yf_k=kjtm9qvc2gnk...@mail.gmail.com
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 26 March 2014 10:13, Cameron Norman wrote: [...] > That is pretty much impossible, according to the developers of the logind > API and its single implementation. Perhaps a subset of the logind API for > use by desktop environments / compositors would be more useful in this init > and OS portability predicament. I think Matthias Clasen, a GNOME developer, > actually recently expressed interest in this from a portable window manager > and compositor's perspective. I can tell you right now, it is *vastly more difficult* to try to adapt programs modified to work with systemd in their current state, than it is to *revert* those programs to their pre-systemd state. There is a huge amount of unknown design parameters that would need to be known to adapt those programs effectively, and since systemd clearly lacks any coherent design, you will not be able to identify coherent ways to fix this. That is your signal to abandon that path right there. Trust me on this, you don't want to try to patch the *current* versions. And what about all the non-systemd improvements made to those programs over the years they worked with systemd? For that, it is *orders of magnitude easier* to take the improvements and adapt them to the pre-systemd version of the program. This is why I specifically mentioned that Debian perform a pre-systemd reversion to escape this mess. Once you have reverted, you can then figure out how to apply the *useful* upgrades to the old programs. This is the easiest path you can take. -Kev -- 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/CADkoAxh2_GyySKzTVOmdTvzSMy8w=pjkhu1u4vj76jtvw-y...@mail.gmail.com
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 26/03/14 17:13, Kevin Toppins wrote: > I am going to have to respectfully disagree with you on my post being useless. With the hope of contributing constructive criticism, I'll answer that. As far as the systemd vs. upstart discussion, I was leaning in upstart (more precisely, against systemd). As such, your email was very interesting to me. Unfortunately, it was unreadable. You said you'll start with background, but instead of providing technical background, you provided meaningless and irrelevant "he said, I said" arguments. Trying to skim ahead to find where the meat starts did not easily detect such a point. At this point, I simply assumed the email had nothing more to say. If I'm wrong, feel free to answer with the technical gist of your arguments. If you want me to read it, please adhere to the following guidelines: * No more than one page. * No *asterisks* and -> arrows. * No references to previous discussions, or other people's arguments for/against systemd. I believe in free discussion. As such, feel free to ignore these suggestions, just as I'll feel free to ignore your email if you do so. Shachar
Re: trolls and Humans are *fundamentally incompatible* -> and you have proven it
On 25/03/14 18:33, Milan P. Stanic wrote: > On Tue, 2014-03-25 at 16:15, Jonathan Dowland wrote: >> I was very proud of my fellow colleagues for not feeding the troll a >> full 24 hours later. Thanks for breaking the record :( > > I had a hope that the no one will answer OP. :( > > -- 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/53332d22.4010...@pocock.com.au
Bug#742735: ITP: tryton-modules-account-invoice-stock -- Account Invoice Stock Module for the Tryton Application Platform
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: Debian Tryton Maintainers * Package name: tryton-modules-account-invoice-stock Version : 3.2.0 Upstream Author : Tryton project (www.tryton.org) * URL : http://downloads.tryton.org/3.2/ * License : GPL-3+ Programming Lang: Python Description : Tryton Application Platform (Account Invoice Stock Module) Tryton is a high-level general purpose application platform written in Python and using PostgreSQL as database engine. It is the core base of a complete business solution. . This package provides links between invoice lines and stock moves. It is needed as a dependency of the sale and purchase modules. This package is another base module published by the Tryton project. signature.asc Description: PGP signature
Bug#742736: ITP: tryton-modules-account-payment -- Account Payment Module for the Tryton Application Platform
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: Debian Tryton Maintainers * Package name: tryton-modules-account-payment Version : 3.2.0 Upstream Author : Tryton project (www.tryton.org) * URL : http://downloads.tryton.org/3.2/ * License : GPL-3+ Programming Lang: Python Description : Tryton Application Platform (Account Payment Module) Tryton is a high-level general purpose application platform written in Python and using PostgreSQL as database engine. It is the core base of a complete business solution. . This package adds the possibility to generate grouped payments for receivable or payable lines. This package is another base module published by the Tryton project. signature.asc Description: PGP signature
Bug#742737: ITP: tryton-modules-account-credit-limit -- Account Credit Limit Module for the Tryton Application Platform
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: Debian Tryton Maintainers * Package name: tryton-modules-account-credit-limit Version : 3.2.0 Upstream Author : Tryton project (www.tryton.org) * URL : http://downloads.tryton.org/3.2/ * License : GPL-3+ Programming Lang: Python Description : Tryton Application Platform (Account Credit Limit Module) Tryton is a high-level general purpose application platform written in Python and using PostgreSQL as database engine. It is the core base of a complete business solution. . This package adds the possibility to manage credit limits for parties. This package is another base module published by the Tryton project. signature.asc Description: PGP signature
Bug#742738: ITP: tryton-modules-account-payment-sepa -- Account Payment SEPA Module for the Tryton Application Platform
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: Debian Tryton Maintainers * Package name: tryton-modules-account-payment-sepa Version : 3.2.0 Upstream Author : Tryton project (www.tryton.org) * URL : http://downloads.tryton.org/3.2/ * License : GPL-3+ Programming Lang: Python Description : Tryton Application Platform (Account Payment SEPA Module) Tryton is a high-level general purpose application platform written in Python and using PostgreSQL as database engine. It is the core base of a complete business solution. . This package adds the possibility to generate SEPA files for grouped payments. This package is another base module published by the Tryton project. signature.asc Description: PGP signature
Bug#742739: ITP: tryton-modules-party-relationship -- Party Relationship Module for the Tryton Application Platform
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: Debian Tryton Maintainers * Package name: tryton-modules-party-relationship Version : 3.2.0 Upstream Author : Tryton project (www.tryton.org) * URL : http://downloads.tryton.org/3.2/ * License : GPL-3+ Programming Lang: Python Description : Tryton Application Platform (Party Relationship Module) Tryton is a high-level general purpose application platform written in Python and using PostgreSQL as database engine. It is the core base of a complete business solution. . This package adds the possibility to define different types of relations between parties. This package is another base module published by the Tryton project. signature.asc Description: PGP signature
Bug#742740: ITP: tryton-modules-sale-credit-limit -- Sale Credit Limit Module for the Tryton Application Platform
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: Debian Tryton Maintainers * Package name: tryton-modules-sale-credit-limit Version : 3.2.0 Upstream Author : Tryton project (www.tryton.org) * URL : http://downloads.tryton.org/3.2/ * License : GPL-3+ Programming Lang: Python Description : Tryton Application Platform (Sale Credit Limit Module) Tryton is a high-level general purpose application platform written in Python and using PostgreSQL as database engine. It is the core base of a complete business solution. . This package adds the possibility to check the credit limit for parties when processing sales. This package is another base module published by the Tryton project. signature.asc Description: PGP signature
Bug#742741: ITP: tryton-modules-shipment-grouping -- Sale Shipment Grouping Module for the Tryton Application Platform
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: Debian Tryton Maintainers * Package name: tryton-modules-sale-shipment-grouping Version : 3.2.0 Upstream Author : Tryton project (www.tryton.org) * URL : http://downloads.tryton.org/3.2/ * License : GPL-3+ Programming Lang: Python Description : Tryton Application Platform (Sale Shipment Grouping Module) Tryton is a high-level general purpose application platform written in Python and using PostgreSQL as database engine. It is the core base of a complete business solution. . This package adds the possibility to define how stock moves generated from sales will be grouped for shipping. This package is another base module published by the Tryton project. signature.asc Description: PGP signature
Bug#742742: ITP: tryton-modules-stock-package -- Stock Package Module for the Tryton Application Platform
X-Debbugs-CC: debian-devel@lists.debian.org Package: wnpp Severity: wishlist Owner: Debian Tryton Maintainers * Package name: tryton-modules-stock-package Version : 3.2.0 Upstream Author : Tryton project (www.tryton.org) * URL : http://downloads.tryton.org/3.2/ * License : GPL-3+ Programming Lang: Python Description : Tryton Application Platform (Stock Package Module) Tryton is a high-level general purpose application platform written in Python and using PostgreSQL as database engine. It is the core base of a complete business solution. . This package allows one to store packaging information about outgoing shipments. This package is another base module published by the Tryton project. signature.asc Description: PGP signature
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 26 March 2014 13:42, Shachar Shemesh wrote: [...] > As far as the systemd vs. upstart discussion, I was leaning in upstart (more > precisely, against systemd). As such, your email was very interesting to me. > Unfortunately, it was unreadable. You said you'll start with background, but > instead of providing technical background, you provided meaningless and > irrelevant "he said, I said" arguments. Trying to skim ahead to find where > the meat starts did not easily detect such a point. > > At this point, I simply assumed the email had nothing more to say. If I'm > wrong, feel free to answer with the technical gist of your arguments. If you > want me to read it, please adhere to the following guidelines: > > No more than one page. > No *asterisks* and -> arrows. > No references to previous discussions, or other people's arguments > for/against systemd. First, here is a version with the asterisks removed. It might be visually easier to read. https://lists.debian.org/debian-devel/2014/03/msg00449.html Second, some concepts need a lot of information communicated to make sense to those who are not already familiar with the concept. We don't send people to college for a day and expect them to grasp 4 years of higher education. There are some limits on Human learning that you have to respect. But here is the vastly oversimplified technical argument... The test of comprehension is... if you cannot put an idea into writing, then you do not understand that idea well enough to be of any practical use. If that idea is a program... this means you do not actually have control of the program when implemented. Our ability to control things is directly dependent on our knowledge of how that thing operates. With knowledge, comes the ability to manipulate the thing to suite our purposes. Please, tell me what systemd is, fitting its entire functionality as expressed as one single concept. That does not mean it has to be one sentence, but it does mean you cannot group different concept together and simply give that as an answer. Grouping them together is saying what it does, not what it is. Big difference. I think you will confirm that neither you, nor I, nor the guy who came up with the original idea actually understands how it works, and we will not actually have control of it in situations where we need to control it. And so we need to pull it out of linux. -Kev -- 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/CADkoAxgmfwpKw-cx4abjQZXK0d+-VgKzbu1Rugk=xtp3efk...@mail.gmail.com
FW: Re: Bug#742729: ITP: gstreamer-sharp-1.0 -- new revamped GStreamer CLI bindings that target gstreamer-1.x
- Forwarded message from Andrei POPESCU - Date: Wed, 26 Mar 2014 22:16:51 +0200 From: Andrei POPESCU To: "Andrés G. Aragoneses" , 742...@bugs.debian.org Cc: debian-de...@packages.debian.org Subject: Re: Bug#742729: ITP: gstreamer-sharp-1.0 -- new revamped GStreamer CLI bindings that target gstreamer-1.x User-Agent: Mutt/1.5.23 (2014-03-12) Control: reassign -1 wnpp On Mi, 26 mar 14, 18:58:52, Andrés G. Aragoneses wrote: > Package: gstreamer-sharp-1.0 > Severity: wishlist > Owner: Andres G. Aragoneses > > * Package name: gstreamer-sharp > Version: 0.99.0 > Upstream Author : Stephan Sundermann > * URL: http://cgit.freedesktop.org/gstreamer/gstreamer-sharp/ > * License: AGPL-3.0 > Programming Lang: C#,C > Description: New GI-based bindings to GStreamer 1.x > > GStreamer-Sharp are C# bindings to GStreamer. This version of the bindings > has been written from scratch, mainly by Stephan Sundermann in GSoC, based > on bindinator (a new GObject-Introspection-based code-generation approach). > This version of the bindings is a "preview" (0.99.0) which means it will be > API-unstable until its final version (1.0), and it targets GStreamer 1.0 > API. Soname of the bound library is libgstreamer-1.0.so.0. > > Banshee v2.9.1 is the first version which consumes this binding, for > example. -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt - End forwarded message - -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
Excerpts from Kevin Toppins's message of 2014-03-26 13:00:22 -0700: > On 26 March 2014 13:42, Shachar Shemesh wrote: > [...] > > As far as the systemd vs. upstart discussion, I was leaning in upstart (more > > precisely, against systemd). As such, your email was very interesting to me. > > Unfortunately, it was unreadable. You said you'll start with background, but > > instead of providing technical background, you provided meaningless and > > irrelevant "he said, I said" arguments. Trying to skim ahead to find where > > the meat starts did not easily detect such a point. > > > > At this point, I simply assumed the email had nothing more to say. If I'm > > wrong, feel free to answer with the technical gist of your arguments. If you > > want me to read it, please adhere to the following guidelines: > > > > No more than one page. > > No *asterisks* and -> arrows. > > No references to previous discussions, or other people's arguments > > for/against systemd. > > > First, here is a version with the asterisks removed. It might be > visually easier to read. > > https://lists.debian.org/debian-devel/2014/03/msg00449.html > > > Second, some concepts need a lot of information communicated to make > sense to those who are not already familiar with the concept. We > don't send people to college for a day and expect them to grasp 4 > years of higher education. There are some limits on Human learning > that you have to respect. > > > But here is the vastly oversimplified technical argument... > > The test of comprehension is... if you cannot put an idea into > writing, then you do not understand that idea well enough to be of any > practical use. > > If that idea is a program... this means you do not actually have > control of the program when implemented. Our ability to control > things is directly dependent on our knowledge of how that thing > operates. With knowledge, comes the ability to manipulate the thing > to suite our purposes. > > Please, tell me what systemd is, fitting its entire functionality as > expressed as one single concept. That does not mean it has to be one > sentence, but it does mean you cannot group different concept together > and simply give that as an answer. Grouping them together is saying > what it does, not what it is. Big difference. Kevin, it would be quite helpful for those who accept this challenge if you could do the same for the pieces of the stack that systemd is meant to replace or is (was?) competing with. So - Sysvinit is ... - Upstart is ... - OpenRC is ... Or since your argument is that Linux fits into this: Linux is ... Thanks. -- 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/1395865553-sup-7...@fewbar.com
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
Hi, Kevin Toppins: > But here is the vastly oversimplified technical argument... > To the point of being neither technical nor valid. (Which admittedly was never in doubt even before I started reading.) > I think you will confirm that neither you, nor I, nor the guy who came > up with the original idea actually understands how it works If understanding how systemd works is so much of a problem for you that you cannot even conceive of anybody, let alone its author, doing so … then I'd like to suggest that debian-devel is not the right place for you. I'd suggest an alternate mailing list, but I'm afraid I'd offent both you and the other participants of that list, should I do so. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Preparing openjpeg 2.0
* Mathieu Malaterre , 2014-03-24, 12:38: I am preparing to upload openjpeg 2.0. This is a major API (yes API) change from previous openjpeg 1.x. None of these openjpeg versions seem to use versioned symbols. If you want to have both in the archive at the same, then both should use them. -- Jakub Wilk -- 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/20140326222020.ga5...@jwilk.net
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 03/26/2014 07:40 AM, Thomas Goirand wrote: > If you want thing to move on, stop posting useless messages, and start > working on alternatives. For example, helping adding more features to > OpenRC would certainly help a way more than this post. going offtopic here, do you know if there is any plan to use cgmanager with openrc, i really like the idea of putting each service in it's own cgroup -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 -- 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/533387ec.2090...@zumbi.com.ar
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
El Wed, 26 de Mar 2014 a las 7:07 PM, gustavo panizzo escribió: On 03/26/2014 07:40 AM, Thomas Goirand wrote: If you want thing to move on, stop posting useless messages, and start working on alternatives. For example, helping adding more features to OpenRC would certainly help a way more than this post. going offtopic here, do you know if there is any plan to use cgmanager with openrc, i really like the idea of putting each service in it's own cgroup I was thinking about how to do something like this without requiring cgmanager to be started before the init system or moving the cgroups management into the init system itself. I wonder if dbus activation could be used to accomplish this. Of course, then one would not be able to put (in the case of Upstart) the socket bridge, dbus bridge, dbus, or anything those services need to boot into a cgroup, but one can still put stuff like Apache, lightdm/gdm/kdm/sddm, nginx, et al into a cgroup. Another option is to push the kernel maintainers to allow delegating parts of the cgroups tree to other processes, so that the init system could say "you get a sub-hierarchy, you get a sub-hierarchy" without the complication of multiple separate hierarchies. How do you suggest this integration with cgroups be done? Best regards, -- Cameron Norman
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 03/26/2014 11:49 PM, Cameron Norman wrote: > El Wed, 26 de Mar 2014 a las 7:07 PM, gustavo panizzo > escribió: >> On 03/26/2014 07:40 AM, Thomas Goirand wrote: >> >> If you want thing to move on, stop posting useless messages, and >> start working on alternatives. For example, helping adding more >> features to OpenRC would certainly help a way more than this post. >> >> going offtopic here, do you know if there is any plan to use cgmanager >> with openrc, i really like the idea of putting each service in it's >> own cgroup > > I was thinking about how to do something like this without requiring > cgmanager to be started before the init system or moving the cgroups > management into the init system itself. i don't see any problem starting cgmanager after init, i don't see much value on a big init or an init daemon confined by a cgroup. I wonder if dbus activation > could be used to accomplish this. Of course, then one would not be able > to put (in the case of Upstart) the socket bridge, dbus bridge, dbus, or > anything those services need to boot into a cgroup, but one can still > put stuff like Apache, lightdm/gdm/kdm/sddm, nginx, et al into a cgroup. > Another option is to push the kernel maintainers to allow delegating > parts of the cgroups tree to other processes, so that the init system > could say "you get a sub-hierarchy, you get a sub-hierarchy" without the > complication of multiple separate hierarchies. How do you suggest this > integration with cgroups be done? i just want to put services inside cgroups, no socket activation, no dbus, no dbus activation. i would use it for servers, apache and friends, what i would really like is to be able to run multiple instances of the same service each on it's own cgroup. something like su - user -g cgroup_name -c command or a flag to start-stop-daemon, cgroups could be created in advance by an init script (a Required-Start in lsb slang) just my 0.02$ of what i would use as sysadmin > > Best regards, > -- > Cameron Norman -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 -- 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/5333a2fe.2040...@zumbi.com.ar
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
El Wed, 26 de Mar 2014 a las 9:03 PM, gustavo panizzo escribió: On 03/26/2014 11:49 PM, Cameron Norman wrote: I wonder if dbus activation could be used to accomplish this. Of course, then one would not be able to put (in the case of Upstart) the socket bridge, dbus bridge, dbus, or anything those services need to boot into a cgroup, but one can still put stuff like Apache, lightdm/gdm/kdm/sddm, nginx, et al into a cgroup. Another option is to push the kernel maintainers to allow delegating parts of the cgroups tree to other processes, so that the init system could say "you get a sub-hierarchy, you get a sub-hierarchy" without the complication of multiple separate hierarchies. How do you suggest this integration with cgroups be done? i just want to put services inside cgroups, no socket activation, no dbus, no dbus activation. Haha. The problem there is that cgmanager uses dbus! So you need dbus installed + started before you can use cgroups with later kernels. i would use it for servers, apache and friends, what i would really like is to be able to run multiple instances of the same service each on it's own cgroup. something like su - user -g cgroup_name -c command or a flag to start-stop-daemon, cgroups could be created in advance by an init script (a Required-Start in lsb slang) I think cgexec is what you are looking for here. This would break with later versions of the linux kernel, though, because you need one centralized writer (e.g. cgmanager or systemd). -- Cameron Norman
