Re: Technical committee acting in gross violation of the Debian constitution
Am Donnerstag, 27. November 2014, 01:19:14 schrieb Josselin Mouette: > Le mercredi 26 novembre 2014 à 16:05 -0800, Russ Allbery a écrit : > > And many of us who actually *are* Debian server administrators have said > > repeatedly that your gut is wrong, in the innumerable versions of this > > conversation that have happened over the past two years. This idea that > > systemd is somehow aimed at desktop environments and is not useful or a > > good idea for servers is complete nonsense. > > Yes, yes, and yes. This needs to be put in a frame and bashed in the > head of anyone who keeps repeating that systemd is about GNOME. > > Desktops (not only GNOME) use a very tiny bit of systemd, interfaces > that could be provided elsewhere. The real purpose of systemd is to > provide a modern init system. I still wonder why there are provided within systemd then. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/1750346.PdfvUZja1x@merkaba
Re: Technical committee acting in gross violation of the Debian constitution
Hi, Martin Steigerwald: > > Desktops (not only GNOME) use a very tiny bit of systemd, interfaces > > that could be provided elsewhere. The real purpose of systemd is to > > provide a modern init system. > > I still wonder why there are provided within systemd then. > Yes, the logind-related parte _could_ be provided elsewhere, but part of the features logind needs is already implemented in systemd. So using that instead of rolling your own from scratch is simply common sense. A second implementation also would require coordination between systemd and whatever, therefore requiring yet more code. More man-hours to write and debug. NB: s/there/they/. -- -- Matthias Urlichs -- 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/20141127105318.ga18...@smurf.noris.de
Re: Technical committee acting in gross violation of the Debian constitution
Am 27.11.2014 um 01:19 schrieb Josselin Mouette: > Yes, yes, and yes. This needs to be put in a frame and bashed in the > head of anyone who keeps repeating that systemd is about GNOME. What about the idea of being mindful of the tone of your conversation and keeping it conciously moderate, Josselin? When you are asking for something to be "bashed in the head" of people other than you, then I think it is trivial to understand that you are setting the response to be of the same tone with respect to agressivity and intollerance. That kind of tone will evidently not contribute to keeping the conversation constructive. If there's something to be learned from the mailing list traffic here then it seems crystal clear to me that the *way* people interact with each other is *the* determining factor of the future of Debian as a project. You must accept that there will be different opinions never mind how stupid they are. If you react with violence and bash people on their heads then that might work for small, fearful minorities, which you will beat out of the project or into silence. But it will not work in a situation like this, where a large and strong part of the project has a different oppinion than you. Technical correctnes and excellence and correct and excellent interaction are conditions sine non qua for a good and excellent project and product. All of these are of course platitudes that you, being a brilliant mind, have no problem to understand. Therefore I want to suggest to you to please to take one step back before pressing reply and to choose the words that you are using here in conversations conciously. *t -- 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/5477053b.4000...@sourcepole.ch
ArchitectureSpecificsMemo
http://wiki.debian.org/ArchitectureSpecificsMemo
Some suggestions for improving this table:
1. About half of the table is taken up with sizeof information, some
of which could be expressed more concisely. (Are all Debian
architectures ILP32 or LP64? Any rare exceptions could be described in
a footnote.)
2. Perhaps it would be better to reverse the axes, particularly if the
sizeof information is simplified and as more and more architectures
are added.
3. A link to a list of system calls might be useful for some people.
4. I'd like to see some information about va_list added as this
sometimes causes portability problems. For example:
On amd64, va_list is a (struct { ... } [1]) with size 24 and alignment
8. (It's an array, so it turns into a pointer in some circumstances.
You can test whether a va_list is equal to zero, for example.)
On arm64, va_list is a (struct { ... }) with size 32 and alignment 8.
(It's not an array. You can't test whether it's zero.)
On armhf, va_list is a (struct { ...}) with size 4 and alignment 4.
(Have I got that right?)
On i386, va_list is a (char *).
Any thoughts? Vehement objections?
Edmund
--
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/CAHDciUdZ4Jmn89Y6Q6ZSMUhgWwn+X5g3R3zxy3ga=FzqjT=j...@mail.gmail.com
Re: ArchitectureSpecificsMemo
On Thu, 27 Nov 2014, Edmund Grimley Evans wrote: > of which could be expressed more concisely. (Are all Debian > architectures ILP32 or LP64? Any rare exceptions could be described in I think so. Probably even all Linux architectures? > 4. I'd like to see some information about va_list added as this > sometimes causes portability problems. For example: TTBOMK va_list is opaque, you may not do that anyway. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- 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/alpine.deb.2.11.1411271238420.28...@tglase.lan.tarent.de
Re: Technical committee acting in gross violation of the Debian constitution
Am Donnerstag, 27. November 2014, 11:53:18 schrieb Matthias Urlichs: > Hi, Hi Matthias, > Martin Steigerwald: > > > Desktops (not only GNOME) use a very tiny bit of systemd, interfaces > > > that could be provided elsewhere. The real purpose of systemd is to > > > provide a modern init system. > > > > I still wonder why there are provided within systemd then. > > Yes, the logind-related parte _could_ be provided elsewhere, but part of > the features logind needs is already implemented in systemd. So using that > instead of rolling your own from scratch is simply common sense. > > A second implementation also would require coordination between systemd and > whatever, therefore requiring yet more code. More man-hours to write and > debug. But I think for most of the people that dislike systemd this is the main concern: systemd is a lot of system building blocks in *one* repository and *one* debian package and while they may be separatable they are not separated. But well, its an upstream topic and I actually tried to bring this upstream, but didn´t seem to be able to bring my point across without getting touchy responses and even personal attacks from the very same people that complained about being personally attacked themselves including, but not limited to Lennart himself, while I at least *tried* to stay away from personal attacks. But while I do not agree with personal attacks I think as long as upstream handles things they way the do they will continue to get the responses they get. But if you just limit your discussion to technical convenience there is no ground to discuss these things and actually get to an agreement. I learned that before I unsubscribed myself from systemd-devel again to *protect myself*. So while I do not see it as black or white, systemd has its advantages, I would need to put both hands before my eyes not to see that, the way upstream and some avid supports of it in Debian deal with the concerns it raises does not seem to be well suited for actually *addressing* those concerns. And this will remain the case as long as technical convenience is the only discussable item here. As long as its all in one big package cause, as according to the responses I got on systemd-devel, it is technically *convenient* and *easier* to develop. That does no good to address these concerns I think. Cause: Technical *convenient* is not necessarely technical *best*. Splitting things may be work… but developers still do it and I think *for good reasons*. Cause, I think part of the issues are *social* issues with the *way* upstream handles concerns and user feedback. Acting in a certain way triggers certain results and I think it is very important that at some point upstream developers and avid systemd supporters within Debian project ask themselves the question: Why do I get *that much* resistance? What, *at the core of it* is the reason behind that resistance? And no… its not all people resisting for the sake of resisting in my oppinion. Of course, also those resisting systemd can benefit from asking themselves: Why do I actually resist systemd? What real issues does it actually cause me? What is the real issue I actually have? And how can I address it? That said, systemd has been discussed to an extent that I never saw *anything* in Debian discussed ever before… so I myself decided to wait a bit what comes out of it. Despite my concerns, so far systemd runs stable on mail laptop, the workstation at work and music laptop and reliably. It still find strange behavior from time to time that I report, like just yesterday changing MAC addresses on eth0 on every disconnect, but this may also be Network Manager doing this (also reported already). But so or so: if systemd fails on technical terms I am pretty sure, Debian developers can adapt and replace the default init system again if need be. So while I have my own share of technical concerns I am more concerned with the social and emotional responses systemd adoption in Debian triggers. As there I see the real danger for the project. And yes, I am concerned about it. Big time. I am still confident that Debian as a community will get through it, but as far as I have seen so far it has been a very rough ride. But for addressing it, for healing what obviously seems to be hurt it is actually absolutely necessary that everyone starts with oneself, cause just attacking each other with accusation will just cause more attacks, more accusation, more frustration, more people leaving. I for myself will no be very strict regarding any technical things I see. I am determined to report any bug with systemd I find. It is under high scrutiny on my systems. For me it still has to prove itself. I don´t take its reliability, stability and well behaving for granted. But that is it… … not much point to discuss here further… without addressing whats really behind the concerns of those who resist systemd and the fru
Bug#769907: New Project for you.
Write to Mrs Ana Rita on anarhom...@outlook.com
Re: ArchitectureSpecificsMemo
On Thu, Nov 27, 2014 at 10:50:26 +, Edmund Grimley Evans wrote:
> http://wiki.debian.org/ArchitectureSpecificsMemo
>
> Some suggestions for improving this table:
>
> 1. About half of the table is taken up with sizeof information, some
> of which could be expressed more concisely. (Are all Debian
> architectures ILP32 or LP64? Any rare exceptions could be described in
> a footnote.)
>
> 2. Perhaps it would be better to reverse the axes, particularly if the
> sizeof information is simplified and as more and more architectures
> are added.
>
> 3. A link to a list of system calls might be useful for some people.
>
> 4. I'd like to see some information about va_list added as this
> sometimes causes portability problems. For example:
>
> On amd64, va_list is a (struct { ... } [1]) with size 24 and alignment
> 8. (It's an array, so it turns into a pointer in some circumstances.
> You can test whether a va_list is equal to zero, for example.)
>
> On arm64, va_list is a (struct { ... }) with size 32 and alignment 8.
> (It's not an array. You can't test whether it's zero.)
>
> On armhf, va_list is a (struct { ...}) with size 4 and alignment 4.
> (Have I got that right?)
>
> On i386, va_list is a (char *).
>
> Any thoughts? Vehement objections?
>
As this is one of the wiki pages that I visit most often: I'd completely agree,
and addition it would be very useful if the macros defined by compilers we use
(GCC, and maybe Clang) to test for a particular architecture were listed as
well. (Yes, we're in do-ocracy, so I should just go and add these...)
Best,
Michael
pgpLAeL93Fj4X.pgp
Description: PGP signature
successful upgrade to jessie - thanks!
Hello list, I hope it's appropriate here, I just wanted to say *thanks to everybody*, in particular the low level package and infrastructure maintainers for the excellent work they've done. Yesterday I've upgraded my laptop with quite massive foreign package sources and installations (qgis packages, backports, stuff from ubuntu PPAs, nodejs, a dozen packages from jessie etc.) from wheezy to jessie. Allthough apt-get dist-upgrade broke half way through due to unresolvable package dependencies, I was able to finish the upgrade via aptitude's ncurses interface. One problem when upgrading via apt-get is that if it breaks then I think there's no way a user that is not *very much* knowledgeable will be ever able to get his system back together. apt-get with or without -f will (in my case) flood the user with a broken dependencies listing which is far, far beyond trivial to act upon. So I think if Debian wants to embrace the "normal" desktop end user, then it *can not* point him to apt-get as the upgrade method of choice. I am not sure how pervasive non-debian package sources (mind you Debian backports are officially listed at Debian, but can break the upgrade none the less!) are in our install base, but there are a lot of upstream projects that do provide Debian packages and respective advice is easily found on the intertubes. I do not know how other Debian users handle tech, but my way of approaching technology is "just try". In the case of a Debian installation with foreign package sources that "apt-get dist-upgrade" approach will quite likely end with a broken system. So I think it'd be good to add a big fat warning to "apt-get dist-upgrade" if it finds non canonical sources to tell the user "you want to break your system now? Please go ahead and type 'YES' now" or have a different way for upgrading for "end users". Another point to note is that the migration to systemd went very smoothly - very few things broke - so applause to all the burned out parties out there and those that are sill holding out: you did a very good job. Thanks a lot! *t -- 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/54772586.9060...@sourcepole.ch
Re: Technical committee acting in gross violation of the Debian constitution
Hi, Martin Steigerwald: > But I think for most of the people that dislike systemd this is the main > concern: systemd is a lot of system building blocks in *one* repository and > *one* debian package and while they may be separatable they are not separated. > > But well, its an upstream topic and I actually tried to bring this upstream, > but didn´t seem to be able to bring my point across What exactly _is_ the point? It's one git repository instead of five, but what (technical) problem would having five repos and five Debian source packages, instead of one, actually solve? IMHO: None at all. Instead it creates busy-work, and a testing headache because you can't depend on a definite version of $OTHER_BINARY any more. There are obviously social problems with merging systemd and udev into one repository, and with having systemd and logind (and/or a couple of other helpers) there. We're seeing them; it's one of the major complaints about systemd. But it's Upstream's decision to do that. Absent a reasonable technical argument, I can understand that Lennart&Co get extremely impatient with having to re-hash the same old non-argument for the umpteenth time, even if not everybody actually gives them flak about it. -- -- Matthias Urlichs -- 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/20141127132801.gb18...@smurf.noris.de
upgrading to jessie broke usb_storage on a mode switched device
Hello, after upgrading to jessie(-with systemd) connecting my mobile to the latop as a usb storage device stopped working. I do have to "rmmod usb_storage && modprobe usb_storage" in order for the usb storage devices to become visible every time. What is the suggested procedure from here on short of filing a bug against "general"? I do not have an idea which component between systemd/udev/usb_modeswitch/the kernel/or other is at fault here, if even it's the fault of a single package at all. Where does the bug belong to? Is this more appropriate for debian-user? ? Thanks, *t -- 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/54772708.1060...@sourcepole.ch
Re: successful upgrade to jessie - thanks!
Hi Tomas, Great you like it! Many people are busy working on smoothing the edges uncovered by all the inflowing bugreports, so the occasional "thanks!" is a nice boost to troop morale. :) On Thu, Nov 27, 2014 at 02:22:14PM +0100, Tomas Pospisek wrote: > Allthough apt-get dist-upgrade broke half way through due to > unresolvable package dependencies, I was able to finish the upgrade via > aptitude's ncurses interface. Please lookup /var/log/apt/term.log and report a bug about the specific failure you see in there. I presume some maintainerscript is failing, preventing configuration of something which ultimately lets dpkg fail with an unresolved dependency error as the package is arguable not correctly installed… Your system state before the upgrade might be of interest to: You can find a backup of it in /var/backups. One of the files names "dpkg.status" with an 'old-enough' date will be it. Note that if apt-get failed "half way through" in the upgrade, aptitude more than likely would have failed just as well as the code running the installation process is shared. The difference between the two is "just" UI and dependency resolution before you press 'y'. Everything after that like the download, consistency check or the installation is the same… It's also not the worst idea to remove stuff from third party repositories before upgrading and only install them again after the upgrade. This way you can sure that they aren't interfering (something which can't be prevented and just works most of the time because you are lucky) and you can recheck that the 3rd party repository is still maintained/supported or if this or a comparable package appeared in Debian. If not, you should think about getting it into Debian… btw: apt-get is actually recommend for dist-upgrade as it is requiring less knowledge than the operation of aptitude. The later can also be a bit unpredictable in its resolution process, which has its advantages in day to day usage maybe with small solutions, but most people don't second-guess solutions involving >=2000 packages and just press 'y'… Point being: If apt-get doesn't work we ought to know so that can be solved one way or the other, but flipping package manager is unlikely to be the way at this stage. [Disclaimer: I (hopefully) don't say that only because I work on apt] Best regards David Kalnischkies P.S.: Despite many people believing it: -f isn't short for --force, but for --fix-broken. It can work on dist-upgrade, but it is probably better you just run "apt-get install -f" instead as adding new problems on top of the existing ones is usually not a good way forward… signature.asc Description: Digital signature
Re: Technical committee acting in gross violation of the Debian constitution
Am Donnerstag, 27. November 2014, 14:28:01 schrieb Matthias Urlichs: > Martin Steigerwald: > > But I think for most of the people that dislike systemd this is the main > > concern: systemd is a lot of system building blocks in *one* repository > > and > > *one* debian package and while they may be separatable they are not > > separated. > > > > But well, its an upstream topic and I actually tried to bring this > > upstream, but didn´t seem to be able to bring my point across > > What exactly _is_ the point? It's one git repository instead of five, but > what (technical) problem would having five repos and five Debian source > packages, instead of one, actually solve? > > IMHO: None at all. Instead it creates busy-work, and a testing headache > because you can't depend on a definite version of $OTHER_BINARY any more. That is *your* oppinion. And thats it. Others are *perfectly* entitled to have *different* oppinions about this. And that… > There are obviously social problems with merging systemd and udev into one > repository, and with having systemd and logind (and/or a couple of other > helpers) there. We're seeing them; it's one of the major complaints about > systemd. > > But it's Upstream's decision to do that. Absent a reasonable technical > argument, I can understand that Lennart&Co get extremely impatient with > having to re-hash the same old non-argument for the umpteenth time, even > if not everybody actually gives them flak about it. … proves the point I was trying to make *exactly*: As long as there is no willingness of upstream to actually deal with these concerns at the level they are raised – which is beyond technical convenience - and as long as those having those concerns do not find a different way to deal with them as to express them without doing much more about them and as long any of the both party have any energy to go on with this, it will go on like this. But it also proves that it makes no sense to even continue on this here now: I made my point. Take it, or leave it. Be upset with it, or not. I made my point and I stand by it. If I created the same outcome, which is resistance in the case of systemd upstream developers, again and again and again and again, I´d ask myself "What is going on here?". If I created the same outcome in the way how I voice my concerns, I´d ask myself the same. Which isn´t happening here at the moment. On neither side. I just wanted to raise this. Take it, or leave it. But if you continue complaining about the outcome… the one and only place where I can change the outcomes I see is myself. You can´t change me who simply messages this point, I can´t change your or the way you write your mails. The ones who resist systemd and the ones who resist systemd can´t change systemd upstream developers. *** So for a change it is required that at one point one starts to look within oneself for a change. *** A first step would be to acknowledge for the different viewpoints. For the systemd developers and supporters to acknowledge for the concerns *whether they agree with them or not*. For the concerned ones to acknowledge for the design and development decisions of systemd upstream *whether they agree with them or not*. I don´t see this happening so far. And this is why people bring this up again, again, again and again. As long as one oppinion is the right one, and the other is the wrong one, this will continue. As soon as different viewpoints become just that – different viewpoints – in the minds of the involved ones, a change can happen. So the real question here is: How long will any of the involved ones continue to create the same outcome over and over and over again? When is the first of the involved human being in this conflict ready to try something different? When are others willing to agree with trying something different? Or when are enough involved beings at least willing to pause spending energy on this any longer to let it rest for a while – and see whether this can facilitate a change in viewpoints due to calming down. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/1619179.66hm6iClCL@merkaba
Re: splitting source packages
On Thu, 27 Nov 2014 14:28:01 +0100 Matthias Urlichs wrote: > Hi, > > Martin Steigerwald: > > But I think for most of the people that dislike systemd this is the > > main concern: systemd is a lot of system building blocks in *one* > > repository and *one* debian package and while they may be > > separatable they are not separated. > > > > But well, its an upstream topic and I actually tried to bring this > > upstream, but didn´t seem to be able to bring my point across > > What exactly _is_ the point? It's one git repository instead of five, > but what (technical) problem would having five repos and five Debian > source packages, instead of one, actually solve? Actually, not particularly thinking of systemd at this point, but in *general* there is a good technical advantage to this approach: migrations & dependency control. It avoids the "fingers in every pie" problem common to a number of source packages in Debian. It particularly applies to source packages with a lot of plugins or where particular sub-components bring in a unique list of build-dependencies or add unique install time dependencies. By having separate source packages, a stable API becomes mandatory. A stable API then means that libpluginA can migrate into testing independently of libbasefoo and libpluginB. Net result: libbase is no longer trapped in endless migration transitions when it is only one plugin/sub-component which is actually affected. Why, if I want to just patch libpluginF, must I download the entire source package of libbasefoo, libpluginA ... libpluginJ and all those build-dependencies and then waste time building all the stuff I don't need and testing it all... Make a stable API and release libpluginA as a separate source package from libpluginF etc. Persuading upstream to create a stable API between components in order to benefit the distributions is a hard sell, I know. However, the more reverse dependencies a package has, the cleaner it needs to be. This approach hard-codes that requirement and ensures that upstream is prevented from an otherwise tempting (but lazy) approach of changing "internal" APIs without due consideration. I have implemented this approach previously (outside Debian, as this particular upstream was all proprietary code) and it works well - providing that upstream make the commitment to a stable API. It has other advantages too: 0: upstream only need to release the components which have changed. 1: a stable API helps other teams develop other add-ons and components 2: it gets back to the Unix philosophy of one tool doing one job - at the source level. 3: It supports a layered test approach - the components which haven't changed only need to be tested against how those components interact with components which have changed, not against every possible permutation as you have to do with a single source package built into separate binaries. 4: It allows components to mature at different rates and focuses effort on only the active parts. Inherently, it encourages upstreams to act like distributions - not monolithic but modular. It is hard to do during rapid development but then it also requires a level of consistency and resilience which can be extremely valuable during rapid development to provide insurance against regressions. Like many methods, it is a lot easier to put into place at the start of a project but a resolute team can impose such an API later quite effectively. > IMHO: None at all. Instead it creates busy-work, and a testing > headache because you can't depend on a definite version of > $OTHER_BINARY any more. ... stable API Let nobody say this is impossible - I've done it, more than once. (I do try not to recommend methods which I haven't personally demonstrated working.) Monoliths are bad, we know this, that's why we are package maintainers. We know the benefits of multiple binary packages - we also need to convince some upstreams to release multiple source packages. (Equally, there is an argument for not having endless tiny packages, so don't take this approach to the opposite extreme.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpA9804je7ax.pgp Description: OpenPGP digital signature
Bug#771202: ITP: ruby-redis-store -- redis stores for Ruby frameworks
Package: wnpp Severity: wishlist Owner: Balasankar C * Package name: ruby-redis-store Version : 1.1.4 Upstream Author : Luca Guidi * URL : http://redis-store.org/redis-store/ * License : Expat Programming Lang: Ruby Description : redis stores for Ruby frameworks -- 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/20141127150840.20187.46680.reportbug@sasalam
Bug#771201: ITP: python-tempest-lib -- OpenStack Functional Testing Library
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-tempest-lib Version : 0.0.1 Upstream Author : OpenStack Development Mailing List * URL : https://github.com/openstack/tempest-lib * License : Apache-2.0 Programming Lang: Python Description : OpenStack Functional Testing Library This package contains the OpenStack Functional Testing Library which is used by the Tempest Functional Testing suite. -- 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/20141127150611.16767.14322.report...@buzig.gplhost.com
Re: Technical committee acting in gross violation of the Debian constitution
Hi, Martin Steigerwald: > > What exactly _is_ the point? It's one git repository instead of five, but > > what (technical) problem would having five repos and five Debian source > > packages, instead of one, actually solve? > > > > IMHO: None at all. Instead it creates busy-work, and a testing headache > > because you can't depend on a definite version of $OTHER_BINARY any more. > > That is *your* oppinion. And thats it. Others are *perfectly* entitled to > have > *different* oppinions about this. I did not dispute that others are entitled to their opinions. But if all they have is an opinion, with no attempt to convey their reasoning to the "other side" (as you are doing now), then said other side is (equally perfectly) entitled to disagree. Unfortunately, that does not always help. As we see … -- -- Matthias Urlichs -- 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/20141127151828.gc18...@smurf.noris.de
Re: splitting source packages
Hi, Neil Williams: > By having separate source packages, a stable API becomes mandatory. You're correct in that it is easier to keep an API stable when you have separate repositories. But that is not a hard requirement. There are other ways to keep APIs stable. Like, for instance, publishing a specification (once you _have_ a stable API) and sticking to that. But when things are in flux and you're in the process of figuring out what the API should look like in the first place, having multiple places to update, which can and will get out of sync, is no fun. -- -- Matthias Urlichs -- 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/20141127152412.gd18...@smurf.noris.de
Re: successful upgrade to jessie - thanks!
On 11/27/2014 09:22 PM, Tomas Pospisek wrote: > Yesterday I've upgraded my laptop with quite massive foreign package > sources and installations (qgis packages, backports, stuff from ubuntu > PPAs, nodejs, a dozen packages from jessie etc.) from wheezy to jessie. That's probably why you had issues upgrading. That's not supported, and breakage in dependencies are to be expected in this kind of cases. Cheers, Thomas -- 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/54774830.2000...@debian.org
Re: upgrading to jessie broke usb_storage on a mode switched device
On 11/27/2014 09:28 PM, Tomas Pospisek wrote: > Hello, > > after upgrading to jessie(-with systemd) connecting my mobile to the > latop as a usb storage device stopped working. > > I do have to "rmmod usb_storage && modprobe usb_storage" in order for > the usb storage devices to become visible every time. > > What is the suggested procedure from here on short of filing a bug > against "general"? I do not have an idea which component between > systemd/udev/usb_modeswitch/the kernel/or other is at fault here, if > even it's the fault of a single package at all. Where does the bug > belong to? Is this more appropriate for debian-user? > > ? > > Thanks, > *t This sounds like an udev/systemd issue. Do you have any kind of logs to provide? Does "dmesg" says something? Anything in the syslog^W systemd journal? Thomas -- 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/54774d74.60...@debian.org
Re: splitting source packages
On Thu, 27 Nov 2014 16:24:12 +0100 Matthias Urlichs wrote: > Hi, > > Neil Williams: > > By having separate source packages, a stable API becomes mandatory. > > You're correct in that it is easier to keep an API stable when you > have separate repositories. But that is not a hard requirement. There > are other ways to keep APIs stable. Like, for instance, publishing a > specification (once you _have_ a stable API) and sticking to that. Programmers are lazy, we all know this. If a #include "local.h" will fix a scoping problem, someone will do it. Keeping to an external specification intended for "others" without rigorous code review is no fun either. So, in practical terms, separate source repositories become all but essential. > But when things are in flux and you're in the process of figuring out > what the API should look like in the first place, having multiple > places to update, which can and will get out of sync, is no fun. It can also be when this approach is actually of the most value as it protects against regressions and complex failures. A stable API protects *against* having to update multiple places at the same time - you add functionality without removing the old functionality, so the external source packages can migrate in their own sweet time. Being out of sync is only a problem if the API is not sufficiently stable or comprehensive. We have symbols files for this kind of thing - at least in some languages... ;-) Fill the deprecated code with warnings if you have to but keep to the API. Fix the components in the order of the severity of the problems with the old code as used in that component. The whole point of a stable API is that backwards and forwards compatibility is retained until such time as there are no extensions or components using that support - at which time the base library goes for a SONAME transition and everyone is happy. Deprecate old functionality without removing the functions, add new functions, migrate through the components gradually. Simple. Start with the API. It's not as if a package which is considered ready for release into the stable suite of multiple distributions can possibly be in such a state of flux that an API cannot be constructed. If it is, the package is release-critical buggy by definition. Broken by design (or lack of). Yes, in the first proof of concept days when maybe you aren't even sure which language(s) or build system to use and it only exists on your own system or a personal VCS repo - then there can be sufficient flux to prevent an API being designed. However, packages in Debian are generally quite a long way on from that point - especially if those packages are to be considered as part of a stable distribution release. Let's move away from upstreams who make it hard to put their software into a collection in a flexible and stable manner. Push back and explain the benefits of small, compartmentalised source packages and a stable API. It will make the work of the release team easier and it will make it easier for developers to improve the code more generally. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpnXYM5ml4x5.pgp Description: OpenPGP digital signature
Re: upgrading to jessie broke usb_storage on a mode switched device
Am 27.11.2014 um 17:12 schrieb Thomas Goirand: > On 11/27/2014 09:28 PM, Tomas Pospisek wrote: >> Hello, >> >> after upgrading to jessie(-with systemd) connecting my mobile to the >> latop as a usb storage device stopped working. >> >> I do have to "rmmod usb_storage && modprobe usb_storage" in order for >> the usb storage devices to become visible every time. >> >> What is the suggested procedure from here on short of filing a bug >> against "general"? I do not have an idea which component between >> systemd/udev/usb_modeswitch/the kernel/or other is at fault here, if >> even it's the fault of a single package at all. Where does the bug >> belong to? Is this more appropriate for debian-user? > > This sounds like an udev/systemd issue. Do you have any kind of logs to > provide? Does "dmesg" says something? Anything in the syslog^W systemd > journal? Yes, /var/log/messages looks like this: Nov 27 13:46:41 hier kernel: [28652.975203] usb 4-1.1: new high-speed USB device number 26 using ehci-pci Nov 27 13:46:41 hier kernel: [28653.068821] usb 4-1.1: New USB device found, idVendor=12d1, idProduct=1037 Nov 27 13:46:41 hier kernel: [28653.068831] usb 4-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=4 Nov 27 13:46:41 hier kernel: [28653.068836] usb 4-1.1: Product: Android Nov 27 13:46:41 hier kernel: [28653.068840] usb 4-1.1: Manufacturer: Android Nov 27 13:46:41 hier kernel: [28653.068844] usb 4-1.1: SerialNumber: 4C8BEFBC3276 Nov 27 13:46:41 hier kernel: [28653.069822] usb-storage 4-1.1:1.0: USB Mass Storage device detected Nov 27 13:46:41 hier kernel: [28653.070344] scsi15 : usb-storage 4-1.1:1.0 Nov 27 13:46:41 hier mtp-probe: checking bus 4, device 26: "/sys/devices/pci:00/:00:1d.0/usb4/4-1/4-1.1" Nov 27 13:46:41 hier mtp-probe: bus: 4, device: 26 was not an MTP device Nov 27 13:46:42 hier usb_modeswitch: switch device 12d1:1037 on 004/026 And that's that. Now when I do "rmmod usb_storage && modprobe usb_storage" the log continues like this: Nov 27 13:46:55 hier kernel: [28666.858764] usbcore: deregistering interface driver usb-storage Nov 27 13:47:01 hier kernel: [28672.635113] usb-storage 4-1.1:1.0: USB Mass Storage device detected Nov 27 13:47:01 hier kernel: [28672.635615] scsi16 : usb-storage 4-1.1:1.0 Nov 27 13:47:01 hier kernel: [28672.635915] usbcore: registered new interface driver usb-storage Nov 27 13:47:02 hier kernel: [28673.633832] scsi 16:0:0:0: Direct-Access LinuxFile-CD Gadget PQ: 0 ANSI: 2 Nov 27 13:47:02 hier kernel: [28673.634382] scsi 16:0:0:1: Direct-Access LinuxFile-CD Gadget PQ: 0 ANSI: 2 Nov 27 13:47:02 hier kernel: [28673.634813] scsi 16:0:0:2: CD-ROM LinuxFile-CD Gadget PQ: 0 ANSI: 2 Nov 27 13:47:02 hier kernel: [28673.636127] sd 16:0:0:0: Attached scsi generic sg2 type 0 Nov 27 13:47:02 hier kernel: [28673.636856] sd 16:0:0:1: Attached scsi generic sg3 type 0 Nov 27 13:47:02 hier kernel: [28673.637294] sd 16:0:0:0: [sdb] Attached SCSI removable disk Nov 27 13:47:02 hier kernel: [28673.640180] sr1: scsi3-mmc drive: 0x/0x caddy Nov 27 13:47:02 hier kernel: [28673.641721] sr 16:0:0:2: Attached scsi generic sg4 type 5 Nov 27 13:47:02 hier kernel: [28673.642690] sd 16:0:0:1: [sdc] Attached SCSI removable disk Nov 27 13:47:11 hier kernel: [28682.358352] sd 16:0:0:0: [sdb] 2310144 512-byte logical blocks: (1.18 GB/1.10 GiB) Nov 27 13:47:11 hier kernel: [28682.363018] sdb: Nov 27 13:47:13 hier kernel: [28684.404459] sd 16:0:0:1: [sdc] 62333952 512-byte logical blocks: (31.9 GB/29.7 GiB) Nov 27 13:47:13 hier kernel: [28684.411152] sdc: sdc1 Nov 27 13:47:23 hier kernel: [28695.050516] FAT-fs (sdc1): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Nov 27 13:47:23 hier kernel: [28695.075737] FAT-fs (sdc1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. -- 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/5477652f.1030...@sourcepole.ch
Re: successful upgrade to jessie - thanks!
On Jo, 27 nov 14, 15:06:17, David Kalnischkies wrote: > > It's also not the worst idea to remove stuff from third party > repositories before upgrading and only install them again after the > upgrade. This way you can sure that they aren't interfering (something > which can't be prevented and just works most of the time because you are > lucky) and you can recheck that the 3rd party repository is still > maintained/supported or if this or a comparable package appeared in > Debian. If not, you should think about getting it into Debian… That has been the standard recommendation in the Release Notes since at least Lenny. Kind regards, Andrei -- 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: Technical committee acting in gross violation of the Debian constitution
On Thu, 27 Nov 2014 01:19:14 +0100, Josselin Mouette wrote: >Desktops (not only GNOME) use a very tiny bit of systemd, interfaces >that could be provided elsewhere. The real purpose of systemd is to >provide a modern init system. Why does it initialize the network, provide an NTP implementation and a radically new logging subsystem then? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1xu5h6-0007gz...@swivel.zugschlus.de
Re: Technical committee acting in gross violation of the Debian constitution
On Thu, 27 Nov 2014 11:53:18 +0100, Matthias Urlichs wrote: >Yes, the logind-related parte _could_ be provided elsewhere, but part of >the features logind needs is already implemented in systemd. So using that >instead of rolling your own from scratch is simply common sense. It would be common sense to move the shared code to a library. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1xu5hp-0007gp...@swivel.zugschlus.de
Re: successful upgrade to jessie - thanks!
On Thu, 27 Nov 2014 23:50:08 +0800, Thomas Goirand wrote: >On 11/27/2014 09:22 PM, Tomas Pospisek wrote: >> Yesterday I've upgraded my laptop with quite massive foreign package >> sources and installations (qgis packages, backports, stuff from ubuntu >> PPAs, nodejs, a dozen packages from jessie etc.) from wheezy to jessie. > >That's probably why you had issues upgrading. That's not supported, and >breakage in dependencies are to be expected in this kind of cases. Updating of such systems has always been a pain, but this time it's going to be a gazillion times more painful. Prepare for pain. Lots of pain. It'll come. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1xu5pv-0007hu...@swivel.zugschlus.de
Re: Technical committee acting in gross violation of the Debian constitution
Am Donnerstag, 27. November 2014, 21:29:40 schrieb Marc Haber: > On Thu, 27 Nov 2014 01:19:14 +0100, Josselin Mouette > > wrote: > >Desktops (not only GNOME) use a very tiny bit of systemd, interfaces > >that could be provided elsewhere. The real purpose of systemd is to > >provide a modern init system. > > Why does it initialize the network, provide an NTP implementation and > a radically new logging subsystem then? Cause it isn´t an init system I thought and read somewhere, but a collection of system building blocks (all in one repo and package), but the homepage still says: "systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts." http://freedesktop.org/wiki/Software/systemd/ But well, a system manager is a quite broad term. system managing can be about anything really. And well, I also wonder why systemd --user functionality is in the *same* binary than the PID 1 stuff… but well… I brought this upstream to no avail. At least the logind stuff appears to be separate: merkaba:~> ps -eo pid,cmd ax | grep "[s]ystemd" 1 /bin/systemd 296 /lib/systemd/systemd-journald 307 /lib/systemd/systemd-udevd 1121 /lib/systemd/systemd-logind 1171 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile -- systemd-activation 1815 /lib/systemd/systemd --user But again, all upstream decisions. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/22499172.fj1IF3kO1J@merkaba
Re: Technical committee acting in gross violation of the Debian constitution
❦ 27 novembre 2014 22:02 +0100, Martin Steigerwald : > And well, I also wonder why systemd --user functionality is in the *same* > binary than the PID 1 stuff… but well… Wild guess: because it manages processes like PID 1? -- /* Fuck me gently with a chainsaw... */ 2.0.38 /usr/src/linux/arch/sparc/kernel/ptrace.c signature.asc Description: PGP signature
Re: splitting source packages
Hi, Neil Williams writes: > Atually, not particularly thinking of systemd at this point, but in > *general* there is a good technical advantage to this approach: > migrations & dependency control. It avoids the "fingers in every pie" > problem common to a number of source packages in Debian. > [...more stuff...] This reasoning is basically "turtles all the way down". Let me give you two examples to illustrate: The first are the coreutils, often invoked as a good example of how to do the unix-philosophy right. But if you look at pretty much any modern implementation of (for example) ls, it certainly breaks with the unix-philosophy *very* violently. It should just give you a listing of all the files, but it also does: • stat()ing (duplicated from stat(1)) • Sorting (duplicated from sort(1)) • Colorization • Column-formatting • --ignore,--hide (duplicated from grep(1)) • String escaping It is also is unnecessarily intertwined with different software: At least on my system there is --dired which only works with emacs. Now it forces me to use emacs, instead of vim, or I have to implement this functionality myself! So really, ls should just offer a simple stable API to list files and if you want colorized output, or more information about the files, you can parse it's output and feed it to stat and/or grep and/or sort. So it should basically just be a thin-wrapper around getdents(2). Though, of course, getdents is just a syscall, so it is just part of example number two: The linux userspace API. Because let's be honest: It is next to impossible, to replace any part of the linux kernel or any module, without having to constantly play catch-up. Because the kernel does not offer any stable APIs to it's modules, you have to develop modules in lockstep with the kernel. If the kernel would offer a stable API, hardware-vendors could just develop their drivers against this API and have it run for every kernel-version. Majorly painless updates for proprietary drivers, finally! Though, of course, there is no good reason, why a graphics-driver should stop at OpenGL (or similar) as a stable-API for it's functionality. After all, this prevents me from rolling my own OpenGL-implementation for this particular driver. In both cases, the devs certainly acknowledged the need for a stable API. But they had to choose one boundary where to provide this. So they made their choice and committed to it. And one can disagree with these choices (in both cases there are people who have very strong opinions that these boundaries are indeed wrong), but ultimately it was the choice of the maintainers, what level of modularity to provide. The same goes for systemd: It actually *does* provide modularity and stable APIs. In your opinion their choice of this boundary was wrong. But boundaries are, in the end, arbitrary and it is ultimately up to the maintainer of the package to decide, where they draw the line. At the very least, if you want them to change their minds, it is up to *you* to provide a justification why *your* choice of boundary is the better one (i.e. no one argues *that* you need stable APIs. The question is at what level and I have so far not seen any good arguments for a different boundary). Best, Axel Wagner -- 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/8738941e43.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me
Re: Technical committee acting in gross violation of the Debian constitution
Marc Haber writes: > On Thu, 27 Nov 2014 01:19:14 +0100, Josselin Mouette > wrote: >>Desktops (not only GNOME) use a very tiny bit of systemd, interfaces >>that could be provided elsewhere. The real purpose of systemd is to >>provide a modern init system. > > Why does it initialize the network, provide an NTP implementation and > a radically new logging subsystem then? In my opinion the fact that it does ship these things *too* is not in conflict with the stated primary purpose. Would you stop using (random example) apache if it started shipping with some often-useful CGI scripts? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- 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/877fyg8emt@vostro.rath.org
Javascript trigger design
Hi, Web application have evolved into monsters that needs lots of javascript. It's very common that these javascript applications are collecting all the .js library they use, concatenate them into a single file, and compress the result using all sorts of tools (node uglify is one of the implementation, but that's not the only one). As much as possible, as good Debian citizens, we do package each and every javascript library into a separate package. But then, if there's an update of that JS library, the Web application package has to somehow know about it, and redo the concatenate & compress job. Otherwise, the web app would continue to use the old version. I have this issue with the OpenStack dashboard (ie: Horizon), but also with a second web app which I'm currently packaging (OpenStack Fuel, which is a deployment software for OpenStack). Though this could of course be generalize to any JS app. It's been a long time I've been thinking about it, and I believe that the only way to do this, would be to use triggers. Though I have never used triggers, and I thought it was a good idea to ask my DD friends and this list about it. Should there be one trigger per web app? How would this work? Thoughts anyone? Jonas maybe, who did lots of JS packaging? Cheers, 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/5477ade6.3030...@debian.org
Re: Technical committee acting in gross violation of the Debian constitution
Am Donnerstag, 27. November 2014, 22:30:15 schrieb Vincent Bernat: > ❦ 27 novembre 2014 22:02 +0100, Martin Steigerwald : > > And well, I also wonder why systemd --user functionality is in the *same* > > binary than the PID 1 stuff… but well… > > Wild guess: because it manages processes like PID 1? That kind of exchange isn´t productive and I explained why already, so I will stop this here. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Bug#771253: ITP: gcab -- Microsoft Cabinet file manipulation tool
Package: wnpp Severity: wishlist Owner: Stephen Kitt * Package name: gcab Version : 0.4 Upstream Author : Marc-André Lureau * URL : https://wiki.gnome.org/msitools * License : LGPL-2.1+ Programming Lang: C Description : Microsoft Cabinet file manipulation tool gcab can list, extract and create cabinet (.cab) files, commonly used as archives to distribute software on Windows. . gcab is similar to cabextract but can create cabinet files. This is a reverse dependency of msitools, see #757007. -- 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/20141127235834.11896.6464.report...@heffalump.sk2.org
Work-needing packages report for Nov 28, 2014
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 621 (new: 1) Total number of packages offered up for adoption: 147 (new: 1) Total number of packages requested help for: 56 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: git-remote-gcrypt (#771020), orphaned 2 days ago Description: encrypted git repositories Installations reported by Popcon: 728 620 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: libmongo-client (#770801), offered 3 days ago Description: Alternate C driver for MongoDB Reverse Depends: libmongo-client-dev libmongo-client-doc libmongo-client0-dbg rsyslog-mongodb syslog-ng-mod-mongodb Installations reported by Popcon: 1733 146 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 1760 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache goplay packagesearch Installations reported by Popcon: 76986 athcool (#278442), requested 3684 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 41 awstats (#755797), requested 127 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4165 balsa (#642906), requested 1159 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 732 cardstories (#624100), requested 1312 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 9 chromium-browser (#583826), requested 1642 days ago Description: Chromium browser Reverse Depends: chromedriver chromium-dbg chromium-l10n design-desktop-web mozplugger Installations reported by Popcon: 25782 cups (#532097), requested 2000 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client cups-core-drivers (64 more omitted) Installations reported by Popcon: 143986 debtags (#567954), requested 1760 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2317 developers-reference (#759995), requested 89 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 15290 ejabberd (#767874), requested 24 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib Installations reported by Popcon: 851 fbcat (#565156), requested 1779 days ago Description: framebuffer grabber Installations reported by Popcon: 156 freeipmi (#628062), requested 1281 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools libfreeipmi-dev libfreeipmi16 libipmiconsole-dev libipmiconsole2 libipmidetect-dev (4 more omitted) Installations reported by Popcon: 5878 gnat-gps (#496905), requested 2282 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 509 gnokii (#677750), requested 894 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6 xgnokii Installations reported by Popcon: 1540 gnupg (#660685), requested 1011 days ago Description: GNU privacy guard - a free PGP replacement Reverse Depends: 0install-core apt aptly arriero bootstrap-base cdebootstrap cdebootstrap-static clamav-unofficial-sigs cloud-utils debbindiff (58 more omitted) Installations reported by Popcon: 174151 gradle (#683666), requested 847 days ago Description: Groovy based build system Reverse Depends: gradle libgradle-plugins-java Installations reported by Popcon: 170 gridengine (#703256), requested 620 days ago Descrip
Re: Javascript trigger design
Am 28.11.2014 um 00:04 schrieb Thomas Goirand: > Hi, > > Web application have evolved into monsters that needs lots of > javascript. It's very common that these javascript applications are > collecting all the .js library they use, concatenate them into a single > file, and compress the result using all sorts of tools (node uglify is > one of the implementation, but that's not the only one). > > As much as possible, as good Debian citizens, we do package each and > every javascript library into a separate package. But then, if there's > an update of that JS library, the Web application package has to somehow > know about it, and redo the concatenate & compress job. Otherwise, the > web app would continue to use the old version. > > I have this issue with the OpenStack dashboard (ie: Horizon), but also > with a second web app which I'm currently packaging (OpenStack Fuel, > which is a deployment software for OpenStack). Though this could of > course be generalize to any JS app. > > It's been a long time I've been thinking about it, and I believe that > the only way to do this, would be to use triggers. Though I have never > used triggers, and I thought it was a good idea to ask my DD friends and > this list about it. Should there be one trigger per web app? How would > this work? > > Thoughts anyone? Jonas maybe, who did lots of JS packaging? At least the Ruby On Rails framework notices an updated JS and will re-compress the whole JS blob from its parts. I don't know about other server side frameworks, but they _should_ be able to do the same. - ? Or there shoould be some switch or some additional plugin or such that enables the same functionality. Or do I missunderstand you? *t -- 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/5477c7b4.90...@sourcepole.ch
Re: Technical committee acting in gross violation of the Debian constitution
It took me time to realize why writing the below didn't feel right in some uneasy way. That's because, allthough being logically completely correct (I boldly assert here...), what I wrote below completely misses the essence and is therefor just bullshit, which we can have a good laugh about. And that actually *does* expresses the essence: we _should_ be laughing! So, dear Josselin, sorry for confronting you with that nonsense, I hope you can chuckle about it gleefully! *t Am 27.11.2014 um 12:04 schrieb Tomas Pospisek: > Am 27.11.2014 um 01:19 schrieb Josselin Mouette: >> Yes, yes, and yes. This needs to be put in a frame and bashed in the >> head of anyone who keeps repeating that systemd is about GNOME. > > What about the idea of being mindful of the tone of your conversation > and keeping it conciously moderate, Josselin? > > When you are asking for something to be "bashed in the head" of people > other than you, then I think it is trivial to understand that you are > setting the response to be of the same tone with respect to agressivity > and intollerance. > > That kind of tone will evidently not contribute to keeping the > conversation constructive. > > If there's something to be learned from the mailing list traffic here > then it seems crystal clear to me that the *way* people interact with > each other is *the* determining factor of the future of Debian as a project. > > You must accept that there will be different opinions never mind how > stupid they are. If you react with violence and bash people on their > heads then that might work for small, fearful minorities, which you will > beat out of the project or into silence. But it will not work in a > situation like this, where a large and strong part of the project has a > different oppinion than you. > > Technical correctnes and excellence and correct and excellent > interaction are conditions sine non qua for a good and excellent project > and product. > > All of these are of course platitudes that you, being a brilliant mind, > have no problem to understand. Therefore I want to suggest to you to > please to take one step back before pressing reply and to choose the > words that you are using here in conversations conciously. > *t > -- 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/5477cbd9.10...@sourcepole.ch
Bug#771267: ITP: jnr-unixsocket -- Java access to native libraries for unix sockets
Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: jnr-unixsocket Version : 0.3 Upstream Author : Wayne Meissner * URL : https://github.com/jnr/jnr-unixsocket * License : Apache-2.0 Programming Lang: Java Description : Java access to native libraries for unix sockets Java Native Runtime (JNR) is a collection of Java libraries to make interfacing with OS-leve features easier. JNR uses an alternate method to JNI or JNA to achieve programming simplicity while still retaining performance. The jnr-unixsocket package provides access in Java to the unix domain socket verions of socket(), listen(), bind(), accept(), connect() and others via the native OS libraries. -- 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/20141124162404.8.18872.reportbug@02ed91797728
Bug#771268: ITP: jnr-enxio -- Java extended native cross-platform I/O library
Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: jnr-enxio Version : 0.4 Upstream Author : Charles Nutter * URL : https://github.com/jnr/jnr-enxio * License : Apache-2.0 Programming Lang: Java Description : Java extended native cross-platform I/O library Java Native Runtime (JNR) is a collection of Java libraries to make interfacing with OS-level features easier. JNR uses an alternate method to JNI or JNA to achieve programming simplicity while still retaining performance. The jnr-enxio package mimcs the standard Java non-blocking I/O (NIO) library by implementing an I/O backend based on calls to the underlying native OS-level functions. This is implementing using the jnr-ffi foreign function interface. -- 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/20141124163222.40.24641.reportbug@02ed91797728
Bug#771269: ITP: jnr-ffi -- Java library for loading native libraries without writing writing JNI code
Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: jnr-ffi Version : 1.0.10 Upstream Author : Charles Nutter * URL : https://github.com/jnr/jnr-ffi * License : Apache-2.0 Programming Lang: Java Description : Java library for loading native libraries without writing writing JNI code Java Native Runtime (JNR) is a collection of Java libraries to make interfacing with OS-level features easier. JNR uses an alternate method to JNI or JNA to achieve programming simplicity while still retaining performance. The jnr-ffi package is a set of abstractions that build on the lower-level libraries implement by the jnr-jffi package. -- 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/20141124164725.134.97922.reportbug@02ed91797728
Re: policy regarding redistributable binary files in upstream tarballs
On Sat, Nov 22, 2014 at 04:44:51PM +0100, Matthias Urlichs wrote: > Hi, > > Troy Benjegerdes: > > How hard would it be to add hooks/helpers to dpkg-buildpackage to know how > > to deal with git and mercurial repositories, and deterministically generate > > the 'source' tar.gz from the repo? > > > Exactly: Get source by adding a vcs-git-commit: field which points to the > sources in question, instead of uploading a huge .tar.?z file. > > > If you take this approach a little farther, I think there's an argument (I > > am not sure it's a good one yet) that the debian source archive will take > > up quite a bit less space if it's using git/mercurial repositories that can > > store a single copy of the same file that's used in 15 different releases, > > while the current approach makes 15 copies in the source packages. > > We usually do not *have* 15 releases. What we do have is updated source, > so the archive's mirrors would need to get five small files (the incremental > git .pack, its local and global indices, the new refs/heads/BRANCH entry, > and a tag created by the autobuilder) instead of one large and > mostly-redundant tar.xz. > > A packed git repo is typically 10…20% larger than the .tar.gz it's built > from, so even with better compression via .xz this would be a win whenever > there's more than one source version in the archive. > > I do plan to investigate this idea further. Sometime after the release. Please also consider mercurial, or at least contact me when you have something with git and I can make sure it works when cloned into mercurial. My argument for this (besides my personal bias), is that a *feature* of mercurial is that history is immutable, while git has the feature which allows rewriting history. (my opinion is that's more of a misfeature) >From a security audit point of view, I would much rather have a clear immutable history of the archive, which I can get with a bunch of tar.xz files. I think I can get a good audit trail from mercurial, but git starts to make me nervous about auditing, especially because I do not like the idea of referring to everything by hash, and I'd rather have something clear like Mercurial's revlog[1][2] format. [1] http://xentac.net/2012/01/19/the-real-difference-between-git-and-mercurial.html [2] http://selenic.com/mercurial/wiki/index.cgi/Presentations?action=AttachFile&do=get&target=ols-mercurial-paper.pdf -- 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/20141128054705.ge29...@nl.grid.coop
Bug#771271: ITP: jnr-jffi -- Low-level library implementing the JNR Java foreign function interface
Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: jnr-jffi Version : 1.2.7 Upstream Author : Wayne Meissner * URL : https://github.com/jnr/jffi * License : Apache-2.0, LGPL3+ Description : Low-level library implementing the JNR Java foreign function interface Java Native Runtime (JNR) is a collection of Java libraries to make interfacing with OS-level features easier. JNR uses an alternate method to JNI or JNA to achieve programming simplicity while still retaining performance. The jnr-jffi package implements the lowest level of the JNR Java foreign function interface. This package is used by the other JNR packages to call functions in OS-level native libraries. -- 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/20141124165414.176.66176.reportbug@02ed91797728
Bug#771272: ITP: jnr-constants -- Java library to encapsulate constants in native libraries
Package: wnpp Severity: wishlist Owner: Tim Potter * Package name: jnr-constants Version : 0.8.5 Upstream Author : Wayne Meissner * URL : https://github.com/jnr/jnr-constants * License : Apache-2.0 Programming Lang: Java, C Description : Java library to encapsulate constants in native libraries Java Native Runtime (JNR) is a collection of Java libraries to make interfacing with OS-level features easier. JNR uses an alternate method to JNI or JNA to achieve programming simplicity while still retaining performance. The jnr-constants package gives Java programs access to platform-level constants, for example errno values. -- 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/20141124170828.208.22242.reportbug@02ed91797728
Re: Javascript trigger design
Le Fri Nov 28 2014 at 01:55:26, Tomas Pospisek a écrit : > Am 28.11.2014 um 00:04 schrieb Thomas Goirand: > > Hi, > > > > Web application have evolved into monsters that needs lots of > > javascript. It's very common that these javascript applications are > > collecting all the .js library they use, concatenate them into a single > > file, and compress the result using all sorts of tools (node uglify is > > one of the implementation, but that's not the only one). > > > > As much as possible, as good Debian citizens, we do package each and > > every javascript library into a separate package. But then, if there's > > an update of that JS library, the Web application package has to somehow > > know about it, and redo the concatenate & compress job. Otherwise, the > > web app would continue to use the old version. > > > > I have this issue with the OpenStack dashboard (ie: Horizon), but also > > with a second web app which I'm currently packaging (OpenStack Fuel, > > which is a deployment software for OpenStack). Though this could of > > course be generalize to any JS app. > > > > It's been a long time I've been thinking about it, and I believe that > > the only way to do this, would be to use triggers. Though I have never > > used triggers, and I thought it was a good idea to ask my DD friends and > > this list about it. Should there be one trigger per web app? How would > > this work? > > > > Thoughts anyone? Jonas maybe, who did lots of JS packaging? > > At least the Ruby On Rails framework notices an updated JS and will > re-compress the whole JS blob from its parts. I don't know about other > server side frameworks, but they _should_ be able to do the same. - ? Unfortunalty no. Many "frameworks" help you build such things but with no update detection. Many frameworks are not running server like RoR but only build tools (Grunt, Yeoman, ...) These tools concat/minify/uglify etc... at build time and then you just put your app under Apache/Nginx and a different language server (to manage the GUI). So there is no awy for all these tools to detect a change and automatically do the modification. 1) A trigger mechanism could indeed inform an additional script (that Debian developper/maintainer should develop per app) and this script could do the job, but on "production" system, I do not think that you would want to do automatically this because this may imply other things, and/or many compilation on your server at the same time (think of a jquery update triggering update of all dependent platforms...). 2) One thing could be that a dependency update triggers a rebuilt of the package with a kinda automatic minor version upgrade and you would benefit from it at next system/app update. >From a deveopper point of view (which I am), I would like idea 1, but from an admin point of view I think it would be idea 2. Olivier > Or > there shoould be some switch or some additional plugin or such that > enables the same functionality. > > Or do I missunderstand you? > *t > > > -- > 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/5477c7b4.90...@sourcepole.ch > >
Re: policy regarding redistributable binary files in upstream tarballs
Hi, Troy Benjegerdes: > My argument for this (besides my personal bias), is that a *feature* of > mercurial is that history is immutable, while git has the feature which > allows rewriting history. (my opinion is that's more of a misfeature) > Git doesn't rewrite history; it merely allows you to point the branch name referring to that history to some other history that's not a direct descendant. With Mercurial you'd have to somehow roll back the reflog to achieve that; git keeps the previous history around, it's just hidden. > >From a security audit point of view, Auditing this is easy: you can tell the git archive (the one you'd have to push to, in order to build your software) to not allow non-fast-forward updates, either globally or (if you decide that playing games with -experimental is OK but others are not) with a hook script. NB: Which part of whose email stack did that >From escape escape from‽ I've last needed to do that sometime in the early paleolithic … > I would much rather have a clear immutable > history of the archive, which I can get with a bunch of tar.xz files. plus their SHA* hashes > I think > I can get a good audit trail from mercurial, but git starts to make me nervous > about auditing, especially because I do not like the idea of referring to > everything by hash, and I'd rather have something clear like Mercurial's > revlog[1][2] format. Well, that hash is just a number which unambiguously refers to one place in the project history. Of course, you need the actual file contents to make sense of the hash. So, you might consider a Mercurial reflog to be roughly the same thing as a git hash _plus_ the pack file you get from "git repack -A -d"ing the repository containing that commit. -- -- Matthias Urlichs signature.asc Description: Digital signature
Re: Javascript trigger design
Hi, Tomas Pospisek: > At least the Ruby On Rails framework notices an updated JS and will > re-compress the whole JS blob from its parts. Does it call stat() on every constituent of these packed JS files on every web request, or does it do that with a periodic background checker? In any case, I'd much rather have a notification method instead of polling. (Doesn't have to be an explicit trigger; inotify() would also work.) -- -- Matthias Urlichs -- 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/20141128071911.ge6...@smurf.noris.de
Re: Technical committee acting in gross violation of the Debian constitution
Le jeudi 27 novembre 2014 à 21:29 +0100, Marc Haber a écrit : > On Thu, 27 Nov 2014 01:19:14 +0100, Josselin Mouette > wrote: > >Desktops (not only GNOME) use a very tiny bit of systemd, interfaces > >that could be provided elsewhere. The real purpose of systemd is to > >provide a modern init system. > > Why does it initialize the network, provide an NTP implementation and > a radically new logging subsystem then? There is nothing in the FUD that’s still being spread that hasn’t been entirely debunked almost a year ago in https://wiki.debian.org/Debate/initsystem/systemd I have nothing to add to what we wrote at that time. And I’m tired of people rehashing the same crap just because they can’t admit they have been wrong. Systemd is here in jessie, the world didn’t fall down like you predicted, and those “bitter rearguard battles” Ian warned us about only achieve a single goal: pissing people off, including three of those who made this possible by their tireless work. This is nothing short of bullying. If you want to help our users, you can contribute to debianfork, or you can improve your packages in Debian. But spreading your bitterness on development forums is only about hurting people. -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1417160729.3187.1.ca...@debian.org
