Bug#697270: PC 32-bit programs fails to work on amd64
On Thu, Jan 03, 2013 at 06:59:49PM +, Ben Hutchings wrote: > dpkg --add-architecture i386 > apt-get update > > The installer doesn't AFAIK provide even the option to do this. (The > i386/amd64 installer images might at least be usable as multiarch APT > sources though.) So this is a usability regression in wheezy. I don't think I got round to updating apt-setup for the new --add-architecture scheme; but the apt-setup/multiarch template does exist and I think that at this point it would count as a bug-fix to make it work properly. Given that, you could at least boot the installer with apt-setup/multiarch=i386. I think that apt-setup/multiarch=i386 should be the default on amd64; but I'm less sure that I could convince anyone that that deserves a freeze exception. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130104130355.ga23...@riva.dynamic.greenend.org.uk
Re: [RFC] Go (golang) packaging
On Thu, Jan 3, 2013 at 12:17 PM, Alastair McKinstry wrote: > On 2013-01-03 08:41, Reinhard Tartler wrote: >> On Wed, Jan 2, 2013 at 10:26 PM, Wouter Verhelst wrote: >>> On Wed, Jan 02, 2013 at 01:05:46PM +0100, Guillem Jover wrote: - Private dependencies, as they leak to rdeps. When a library uses another library privately this dependency gets linked in directly in all other rdeps, when that library stop depending on that private dependency, all rdeps need to be rebuilt. >>> Strictly speaking, if you're only using static libraries this is not >>> really true; once you've compiled something against a static library, >>> the static library might change in whatever way it sees fit, the >>> compiled binary will continue to work, with or without recompilation. >> Consider this from the application perspective: Say an application >> links against a library libfoo.a. At some point, libfoo decides to >> include compression support, and requires functionality from libz. No >> problem for the library package maintainer; he just adds a >> build-dependency on libz-dev, and uploads the package. At some point >> the security team needs to update the application and finds the >> package to FTBFS because libz is missing. The solution, of course, is >> now to extend the build-dependencies of the application package. >> However, this is not obvious and in any case more effort than a >> binNMU. >> > Yes, there are compile-time dependencies for any static library. We do > need to track > these. In practice we already have a mechanism in pkg-config, but this > is (I believe) > not properly formalised in Debian. and generally pretty broken: see e.g. #622931 IIRC, the pkg-config maintainer dislikes static linking and the situation is that many if not most .pc files in Debian do not fully declare all dependencies that would be required for static linking. > > In the case you mention, if libfoo now depends on libz, adding a build > dependency > on libz-dev fixes the problem with libfoo.so as it will automatically > pull in libz.so Yeah, which does not really scale IMO. And doesn't solve the issue that the application still needs to track the exact version of all libraries that were used for linking, e.g. using the Built-Using header. > However, the packager should _also_ provide a pkg-config file and this > will have > a list of the dependencies , so > LIBS:=` pkg-config --static -libs foo` > does the right thing, and the updated libfoo-dev package will include > -lz on the libs line. > > I think we should do the following: > > (1) pkg-config files for libraries, in particular all those that ship > static libs, to be a > release goal for jessie. I would vote against this. It is really not worth the trouble. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caj0ccebgukghydrxwfgn3h6rc+3kmczwxkea8mjru6geewk...@mail.gmail.com
Re: Time to merge back ubuntu improvements!
Le vendredi 4 janvier 2013 05:44:57, The Wanderer a écrit : > > That doesn't seem to match my experience. > > I most commonly encounter apt-listbugs bug lists via 'apt-get > dist-upgrade'. If I say "no" in response to the list of bugs, and then run > 'apt-get dist-upgrade' again, I see the same list of bugs. (I just did > this again, and checked /et/apt/preferences ; that file does not exist, > and /etc/apt/preferences.d/ is empty.) > > I don't nearly as often encounter apt-listbugs bug lists via 'apt-get > install [packagename]', but I do seem to recall that in cases where I have > done so, saying "no" and re-running the same command likewise produced the > same bug list; at the very least, it didn't try to prevent me from > installing the version which had been listed as buggy. (Nor would I want > it to, at least not without a way to override the block just as > conveniently as it was set up in the first place.) > > So either I'm not understanding what you mean by this description, or what > you're describing doesn't seem to be happening on my system. I think Gregor is describing the behavior when choosing p instead of n. In that case it sets a pinning and you don't see the bugs again. Best regards. signature.asc Description: This is a digitally signed message part.
Re: Time to merge back ubuntu improvements!
On 01/04/2013 09:15 AM, Thomas Preud'homme wrote: Le vendredi 4 janvier 2013 05:44:57, The Wanderer a écrit : That doesn't seem to match my experience. I most commonly encounter apt-listbugs bug lists via 'apt-get dist-upgrade'. If I say "no" in response to the list of bugs, and then run 'apt-get dist-upgrade' again, I see the same list of bugs. (I just did this again, and checked /et/apt/preferences ; that file does not exist, and /etc/apt/preferences.d/ is empty.) I don't nearly as often encounter apt-listbugs bug lists via 'apt-get install [packagename]', but I do seem to recall that in cases where I have done so, saying "no" and re-running the same command likewise produced the same bug list; at the very least, it didn't try to prevent me from installing the version which had been listed as buggy. (Nor would I want it to, at least not without a way to override the block just as conveniently as it was set up in the first place.) So either I'm not understanding what you mean by this description, or what you're describing doesn't seem to be happening on my system. I think Gregor is describing the behavior when choosing p instead of n. In that case it sets a pinning and you don't see the bugs again. I wasn't even aware this was an option; I don't think I even noticed the '...' in the apt-listbugs prompt, indicating that there are more options available to be chosen. (The existence of those options doesn't seem to be documented in the man page either, only in the prompt-time ? help text.) I don't think I'd want to use that option anyway, at least not without a better understanding of the expected behavior of the resulting scenario (and how to override it if necessary). Still, it's good to know it's there, and at least the confusion seems to be cleared up. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e6edb5.4060...@fastmail.fm
Re: Time to merge back ubuntu improvements!
Im adding the cut-team to the loop. Original message: http://lists.debian.org/debian-devel/2013/01/msg00082.html On Thu, Jan 3, 2013 at 8:15 PM, Carlos Alberto Lopez Perez wrote: > AFAIK there is already an ongoing effort to provide an usable updated > rolling release of Debian. > > http://joeyh.name/code/debian/cut/ > > http://cut.debian.net/ > > > Isn't this (more or less) what you are asking for? I watched the bof 2 years ago, and had it on my initial pre-draft, but since i didnt heard much about it and looking at the page/mailing list it looked dead so i removed it. Even the repository links [0] gave 404 [1]. After closer looking, there must have been some change in s.d.o that needs the url ended in / for the link to work [2]. So I guess is not that dead afterall, it has just not having enough attention after the freeze for obvious reasons. I have not tried myself, so i cant really talk. CUT is kind of more ambitious than what i was asking for, since it tries to provide a working installer as well as working snapshot of debian. Not sure of the criteria for the snapshot tho. Does it just look for a complete working dependence graph or does it look for RC bugs as well? The few people on the list seems happy with it. If this is working well, it needs a little more love on debian.org and a 'testing-cut' link in the repos pointing to latest cut, so it can be set on sources.list and forgotten. On Thu, Jan 3, 2013 at 11:45 PM, gregor herrmann wrote: > On Thu, 03 Jan 2013 19:18:27 +0100, alberto fuentes wrote: > >> The only ways to prevent this if you are running the more or less >> up-to-date testing are: >> * Pin packages with RC bugs on upgrade. This is: >> - Non trivial: it makes you understand how bad the bug is and know how >> the pinning system works > > No and yes. > > No, because apt-listbugs exists and provides a nice interface so users > don't have to care about pinning details for themselves. > > Yes, because from my very practical experience users are often > confused when apt-listbugs presents them a bug subject. > My point with this proposal is to make testing 'usable' for a larger audience. So yes, you agree with me, its non trivial to use. >> - Ineffective: its a matter of luck that the bug is found before you >> upgrade the package. In the worst case scenario, the package entered >> testing one second before you tried to upgrade and has not being broadly >> tested yet to find those pesky RC bugs. > > Pesky RC bugs are usually reported within few hours after they enter > unstable, no danger for testing here. I usually put off the whole upgrade when apt-listbugs reports some RC that I think it can hit me instead of pinning. I did not know the pinning was automatically removed when fixed, but I didnt want the latest of the latest that bad, so putting off the whole thing was okay for me... Even doing this I was hitted with about 3 bugs this year that affected my desktop experience badly. I would dig my own examples, but i think we can agree that testing is usable most of the time. Cases are rare, but it does happen from time to time. 'usable' intends to remove those rare cases. >> - Useless if you are trying to install a new package and the bug >> already hit testing > > Use apt-listbugs. apt-listbugs just will prevent me to install the software. Witch is so so. With 'usable' you still will be able to install a previous version of the software. So what i meant is, it's useless if you really want to install the software. On Fri, Jan 4, 2013 at 7:30 AM, Reinhard Tartler wrote: > On Thu, Jan 3, 2013 at 7:18 PM, alberto fuentes wrote: >> _Rationale_: >> In current state, stable has packages that are too old. >> Testing, as usable as usually is, occasionally breaks. It broke 3 times more >> or less this year to me. These breakages render a poor desktop user >> experience. > > Why did testing break for you? Why do you think that adding another > stage, in which packages migrate automatically after some time period, > will magically prevent that? > > I'm convinced it will not. You can help here much more by improving > testing instead of making our release process much more complicated > than needed. I think that these bugs will be caught up before it hits 'usable'. It will try to do so by being 2-4 weeks behind testing. Adding it between stable and testing will make it more complicated, i guess... but if this seems like nightmare for the release process, it could be added as a branch hanging from testing without anything else added. Thats it, just leaving it out of the chain stable <- testing <-sid I think it overall involves less work than other solutions and I fail to see how me helping in testing as you suggest would prevent testing being not suitable for all audiences greets! [0]http://lists.alioth.debian.org/pipermail/cut-team/2012-August/000344.html [1]http://snapshot.debian.org/archive/debian/20120713T212116Z [2]http://snapshot.debian.org/archive/debian/
Re: ITA: jabberd2 -- Jabber instant messenger server
Ping.. Can somebody from the XMPP or maintainers take a look at the package? https://mentors.debian.net/package/jabberd2 Thanks, Willem On Sat, 2012-12-29 at 14:16 +0100, Willem van den Akker wrote: > Hi, > > I cleaned up the code a little bit. Solved a bunch of lintian > warnings. > I tried to create a git repository on git.debian.org > in /git. But > didnt had the permission for it. > > Please check the changes and let me know if something need to be > changed. > > Greetings, > Willem > > On Wed, 2012-12-26 at 20:50 -0200, Thadeu Lima de Souza Cascardo > wrote: > > > On Wed, Dec 26, 2012 at 12:53:53AM +0100, Willem van den Akker wrote: > > > Hi, > > > > > > I havent received any response about my ITA message for Jabberd2 (see > > > below). > > > It seems the current maintainer is MIA. > > > Is it possible someone of the pkg-xmpp-devel group can reply? > > > > > > I would like to adopt it, but must get a chance to get so ;) > > > > > > Greetings, > > > Willem > > > > > > > Hi, Willem. > > > > Jorge Salamero used to be the main maintainer of jabberd2. I accepted to > > be a comaintainer in the xmpp team, which has seen most work coming from > > Marcelo "Metal" on some Javascript XMPP packages. > > > > I have no problems with you either working with us on a common > > repository as a team to maintain jabberd2, or adopting it entirely. Of > > course, we'd rather see it as a community maintainership, using the xmpp > > infrastructure as it is already setup. > > > > Do you have a git repository with your changes? > > > > Regards. > > Thadeu Cascardo. > > > > > On Thu, 2012-12-20 at 23:28 +0100, Willem van den Akker wrote: > > > > > > > Package: wnpp > > > > > > > > Severity: normal > > > > X-Debbugs-CC: debian-devel@lists.debian.org > > > > > > > > Hi, > > > > > > > > I am interested in adopting jabberd2. > > > > Now a new version of udns is uploaded into unstable, I hope we can > > > > update jabberd2 also. > > > > > > > > I have placed a new version online: > > > > https://mentors.debian.net/package/jabberd2 > > > > > > > > I hope you can check if it is valid and upload if it is. > > > > If not, I will correct it ;) > > > > > > > > Greetings, > > > > Willem vdAkker > > > > > > > > > > > > signature.asc Description: This is a digitally signed message part
Re: Time to merge back ubuntu improvements!
Hi Alberto, hi all, On Do 03 Jan 2013 19:18:27 CET alberto fuentes wrote: Ubuntu has done some poor decisions but it has done some other that are okay. We should consider merging some of them back. Im thinking about the 6 months release thing. Without further ado, here's the proposal pre-draft: _Proposal_: Add a new release stage between stable and testing. Called usable or whatever name we find fit for it stable <- <- testing <- sid I use Debian backports for squeeze a lot at the moment and I must say this satisfies my needs perfectly. Would that be an option for you instead of injecting some inbetween releases? The stable installer / system core of Debian stable and then additionally a great choice of recent software from backports. Works perfectly, even for end customers of mine. Slightly different approach: However, for serious server deployments we in Debian might want to think about supporting older releases a little longer than atm. A scheme like veryoldstable -> oldstable -> stable -> testing -> unstable From the perspective of someone administrating several deployments a support range of 5 years would be very welcome. Like Ubuntu LTS (so that nobody can say, my mail is getting off-topic ;-) ). (The lifetime of lenny e.g. was apprx. 3 years.) Regards + Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, rothenstein 5, 24214 neudorf-bornstein fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpdrU4Aws0rs.pgp Description: Digitale PGP-Unterschrift
Bug#697404: ITP: libnxt -- Simple command-line tool for Lego NXT
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package name: libnxt Version: 0.3 Upstream Author: David Anderson URL: http://code.google.com/p/libnxt/ License: GPL Description: LibNXT is an utility library for talking to the LEGO Mindstorms NXT intelligent brick at a relatively low level. It currently does: * Handling USB communication and locating the NXT in the USB tree * Interaction with the Atmel AT91SAM boot assistant * Flashing of a firmware image to the NXT * Execution of code directly in RAM. The package provides two binary files: * fwexec to upload image file to NXT brick and then execute it * fwflash to flash firmware image to NXT brick regards -- Slavko http://slavino.sk signature.asc Description: PGP signature
Re: Time to merge back ubuntu improvements!
What is the defference: 1. Insert a new stage between "stable" and "testing" and 2. double the period of automatic migration from "unstable" to "testing"? m? :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALL-Q8x8+H4jD_WTvgby7BqFdRJB46rJMgXiOjd=wdaa_1e...@mail.gmail.com
Re: Time to merge back ubuntu improvements!
On Fri, Jan 04, 2013 at 10:09:42PM +0100, Mike Gabriel wrote: > Hi Alberto, hi all, Hi Mike > > On Do 03 Jan 2013 19:18:27 CET alberto fuentes wrote: > > >Ubuntu has done some poor decisions but it has done some other that are > >okay. We should consider merging some of them back. > >Im thinking about the 6 months release thing. Without further ado, here's > >the proposal pre-draft: > > > >_Proposal_: > >Add a new release stage between stable and testing. Called usable or > >whatever name we find fit for it > > > >stable <- <- testing <- sid > > I use Debian backports for squeeze a lot at the moment and I must > say this satisfies my needs perfectly. Would that be an option for > you instead of injecting some inbetween releases? > > The stable installer / system core of Debian stable and then > additionally a great choice of recent software from backports. Works > perfectly, even for end customers of mine. > > Slightly different approach: However, for serious server deployments > we in Debian might want to think about supporting older releases a > little longer than atm. > > A scheme like > > veryoldstable -> oldstable -> stable -> testing -> unstable > > From the perspective of someone administrating several deployments a > support range of 5 years would be very welcome. Like Ubuntu LTS (so > that nobody can say, my mail is getting off-topic ;-) ). (The > lifetime of lenny e.g. was apprx. 3 years.) Well LTS from Ubuntu sounds quite cool but as far as I know the 5 year support period is only for the core system, and quite for good reasons: Today most software tends to have rapid development cycles and bugs and security problems mostly get fixed through new releases. Keeping up with backporting patches for such a long period can become a real PITA... > > Regards + Greets, > Mike Kind regards Harald > > > -- > > DAS-NETZWERKTEAM > mike gabriel, rothenstein 5, 24214 neudorf-bornstein > fon: +49 (1520) 1976 148 > > GnuPG Key ID 0x25771B31 > mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de > > freeBusy: > https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130104232041.gd14...@harald-has.a-little-linux-box.at
Bug#697421: ITP: unidic-mecab -- free Japanese Dictionaries for mecab
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-CC: debian-devel@lists.debian.org, debian-de...@lists.debian.or.jp Package name: unidic-mecab Version: 2.1.1 Upstream Author: The UniDic Consortium URL: http://sourceforge.jp/projects/unidic/ License: BSD-3-cluase LPGL-2.1 GPL-2 Description: free Japanese Dictionaries for mecab unidic-mecab is a Dictionary for MeCab, Japanese morphological analysis implementation. . * All entries are based on the definition of "SUW (short-unit word)" that is specified by NINJAL (The National Institute for Japanese Language and Linguistics), which provides word segmentation in uniform size suited for linguistic research. * It has three-layered structure with - lemma - form - spelling And it can provide a clear distinction of two types of word variant: spelling variant and form variant. * It is useful for research of Speech processing since it can be added accent and shift in sound information. note: please fix weird description (in Japanese)詳しい人がいたら説明文を適宜修正してください -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130105092403.fc1b75e6b4efade17e2d3...@debian.or.jp
Re: Time to merge back ubuntu improvements!
On Sat, Jan 5, 2013 at 5:09 AM, Mike Gabriel wrote: > Slightly different approach: However, for serious server deployments we in > Debian might want to think about supporting older releases a little longer > than atm. > > A scheme like > > veryoldstable -> oldstable -> stable -> testing -> unstable > > From the perspective of someone administrating several deployments a support > range of 5 years would be very welcome. Like Ubuntu LTS (so that nobody can > say, my mail is getting off-topic ;-) ). (The lifetime of lenny e.g. was > apprx. 3 years.) Please check out these links if you want to make this happen. Probably an initial target of supporting oldstable for the same length of time as stable (instead of just a year) is a good first goal to achieve before adding more supported suites. http://lists.debian.org/debian-security-announce/2011/msg00238.html http://www.debian.org/News/2012/20120209 http://wiki.debian.org/DebianSecurity/Meetings/2011-01-14 http://lists.debian.org/debian-devel-announce/2011/01/msg6.html http://lists.debian.org/debian-security/2011/10/msg00029.html http://lists.debian.org/debian-security/2011/10/msg00030.html http://lists.debian.org/debian-security/2011/10/msg00033.html http://lists.debian.org/debian-security/2011/10/threads.html#1 -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6es6y_qs5fuq6_zwzqunmmx17vm-pcnekaq8-s--a_...@mail.gmail.com
Re: Time to merge back ubuntu improvements!
On 01/05/2013 01:28 AM, alberto fuentes wrote: > The few people on the list seems happy with it. If this is working > well, it needs a little more love on debian.org and a 'testing-cut' > link in the repos pointing to latest cut, so it can be set on > sources.list and forgotten Yes, we need to advertize more about CUT. CC-ing debian-www@lists.d.o in the hope the www team can link to CUT install instructions from our home page. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e7bbe7.4060...@debian.org
Re: Time to merge back ubuntu improvements!
On 01/05/2013 09:50 AM, Paul Wise wrote: > > Please check out these links if you want to make this happen. Probably > an initial target of supporting oldstable for the same length of time > as stable (instead of just a year) is a good first goal to achieve > before adding more supported suites. I agree. It would be nice if it was at least possible to upload security updates right now to old-stable, even if that wasn't officially supported. At least, this would be a nice way to go forward (eg: based on "best effort", and without forcing added work on anyone (yet)). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e7c22d.1010...@debian.org
