Re: please test with tiff 4.0.0~beta4 from experimental
Bernd Zeimetz writes: > Jay Berkenbilt wrote: >> If you maintain a debian package that directly uses libtiff or if you >> maintain software that uses libtiff, it would be a great help if you >> could test your packages against the version of libtiff in experimental, >> 4.0.0~beta4. If you find any problems, please report them as bugs >> against the tiff package in the debian BTS. If you test and everything >> works fine, I'd like to know that as well as I can communicate back to >> upstream. > > I gave radiance a try and everything seems to work as expected. Just uploaded > it > to unstable in case somebody wants to play with the latest cvs head and the > new > libtiff. Unstable or experimental? If you build against experimental libtiff then you should have uploaded to experimental. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: please test with tiff 4.0.0~beta4 from experimental
Goswin von Brederlow wrote: > Bernd Zeimetz writes: > >> Jay Berkenbilt wrote: >>> If you maintain a debian package that directly uses libtiff or if you >>> maintain software that uses libtiff, it would be a great help if you >>> could test your packages against the version of libtiff in experimental, >>> 4.0.0~beta4. If you find any problems, please report them as bugs >>> against the tiff package in the debian BTS. If you test and everything >>> works fine, I'd like to know that as well as I can communicate back to >>> upstream. >> I gave radiance a try and everything seems to work as expected. Just >> uploaded it >> to unstable in case somebody wants to play with the latest cvs head and the >> new >> libtiff. > > Unstable or experimental? If you build against experimental libtiff > then you should have uploaded to experimental. Err yes. s/unstable/experimental/ -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dep3 nit-picks
[ moving to -devel from a private discussion to have more feedback ] Daniel was asking me how several unstructured paragraphs are supposed to be treated for the Description field. I told him that the description is the concatenation of all of them. Do other people agree with Daniel that the points that he raises need clarifications? DEP URL for reference: http://dep.debian.net/deps/dep3/ On Thu, 05 Nov 2009, Daniel Kahn Gillmor wrote: > On 11/05/2009 02:45 AM, Raphaël Hertzog wrote: > > It's the concatenation of all of them. Can you suggest a wording that > > would make it more clear? > > what about: > > Any parser that expects those fields in patch headers should also > accept non-structured content and simply append the non-structured > content to the value of the `Description` field. Looks reasonable. > A few more nit-picks that i just noticed: > > 2) there is a distinction made between the header and the pseudo-header, > but it's not clear if the placement of fields in one or the other has > any meaning. Is information in the pseudo-header expected to be treated > any differently than information in the regular header? > > I think the answer is "no, there is no difference", but the document > never says that explicitly, and the act of naming the second header > implies that the name will be used elsewhere in the document, though it > never is. (as someone immersed in debian lore, i assume that the act of > naming the pseudo-header is to give readers a point of reference to the > BTS, the other place where two sets of 2822-like headers show up -- but > that's implicit in the context, and not explicit in the document). How can we make that explicit? Would replacing « (the “pseudo-header”) » with « (sometimes called the “pseudo-header” in other contexts) » be appropriate? > 3) multiple copies of a given field? section 3.6 of RFC 2822 gives > counts of the number of times a given field may appear in a header: > > http://tools.ietf.org/html/rfc2822#section-3.6 > > The only field in DEP3 that explicitly says it can be used multiple > times is Reviewed-By or Acked-By Not true, it's also said for Bug/Bug-/Author/From > -- but i don't see anything else that > says that the other fields *cannot* be used multiple times. Do we really need to make that explicit? Description/Subject/Forwarded/Last-Update/Origin are expected to be unique. > 4) Reviewed-By is semantically unclear. I can review something and > decide it's a bad idea. In that case, it has been reviewed by dkg, but > would it really be Reviewed-By: dkg? probably not (i'm assuming there's > considered to be no semantic difference between Reviewed-By and > Acked-By). I'm not suggesting that we change the header label > necessarily (and i don't know why it was changed from Signed-off-by to > Reviewed-by in the first place -- can you point me to any discussion > about that change?), but if "Reviewed-By" is going to have any sort of > "stamp of approval" connotation, it should be explicitly noted someplace. It has an implicit meaning of approval yes. If the review was negative, it should not be added or it should be clarified in the Description what the reviewer's comments were (always a good idea). Proposition of patches welcome. Please search the debian-devel archives for the discussion about the rename. It was in june IIRC. Signed-off-by has precisely been dismissed because it doesn's have this approval connotation. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dep3 nit-picks
On 11/05/2009 04:44 PM, Raphael Hertzog wrote: > It has an implicit meaning of approval yes. If the review was negative, it > should not be added or it should be clarified in the Description what the > reviewer's comments were (always a good idea). > > Proposition of patches welcome. Please search the debian-devel archives > for the discussion about the rename. It was in june IIRC. Signed-off-by > has precisely been dismissed because it doesn's have this approval > connotation. This appears to be the reason: http://lists.debian.org/debian-devel/2009/06/msg00459.html the implication is that people "signing off" on a patch haven't necessarily read the code directly, but are approving it. I assume the goal is to imply both "i've read it" and "i approve it" with a single header, right? Since i know of no single word for this, i'd be fine with explicitly stating that is the intent in DEP-3 description of the Reviewed-By field, with just: s/reviewed by someone/reviewed and approved by someone/ --dkg signature.asc Description: OpenPGP digital signature
Re: dep3 nit-picks
On Thu, Nov 5, 2009 at 4:44 PM, Raphael Hertzog wrote: > [ moving to -devel from a private discussion to have more feedback ] > > Daniel was asking me how several unstructured paragraphs are supposed to > be treated for the Description field. I told him that the description is > the concatenation of all of them. Do other people agree with Daniel that > the points that he raises need clarifications? > > DEP URL for reference: http://dep.debian.net/deps/dep3/ > > On Thu, 05 Nov 2009, Daniel Kahn Gillmor wrote: >> On 11/05/2009 02:45 AM, Raphaël Hertzog wrote: >> 4) Reviewed-By is semantically unclear. I can review something and >> decide it's a bad idea. In that case, it has been reviewed by dkg, but >> would it really be Reviewed-By: dkg? probably not (i'm assuming there's >> considered to be no semantic difference between Reviewed-By and >> Acked-By). Workflows can differentiate between Reviewed-By and Acked-By, but that's not necessary (e.g., Reviewed-By indicates a positive review, Acked-By indicates approval to commit). >> I'm not suggesting that we change the header label >> necessarily (and i don't know why it was changed from Signed-off-by to >> Reviewed-by in the first place -- can you point me to any discussion >> about that change?), http://article.gmane.org/gmane.linux.debian.devel.general/141581 >> but if "Reviewed-By" is going to have any sort of >> "stamp of approval" connotation, it should be explicitly noted someplace. > > It has an implicit meaning of approval yes. If the review was negative, it > should not be added or it should be clarified in the Description what the > reviewer's comments were (always a good idea). Right. I'd think that if there were a negative review, the proposer of the patch would go back to work on it further before resubmitting. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dep3 nit-picks
On Thu, 05 Nov 2009, Daniel Kahn Gillmor wrote: > I assume the goal is to imply both "i've read it" and "i approve it" > with a single header, right? Yes. > Since i know of no single word for this, i'd be fine with explicitly > stating that is the intent in DEP-3 description of the Reviewed-By > field, with just: > >s/reviewed by someone/reviewed and approved by someone/ Looks reasonable too, also added to my next batch of updates. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
binutils-gold and symbols files
As I received a couple of bug reports today about packages FTBFS, I installed binutils-gold and tried to compile a few of my packages with it. What I noticed is, that every package with symbols file, produced a lintian error, as binutils-gold added new symbols, the most common one was e...@base What's the reason for those additional symbol(s) with binutils-gold? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Work-needing packages report for Nov 6, 2009
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: 670 (new: 64) Total number of packages offered up for adoption: 154 (new: 4) Total number of packages requested help for: 53 (new: 1) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: antennavis (#553390), orphaned 6 days ago Description: antenna visualization software Installations reported by Popcon: 76 bbkeys (#553347), orphaned 6 days ago Description: A key-grabber for any NETWM/EMWH-compliant window manager Installations reported by Popcon: 205 blackbox-themes (#553348), orphaned 6 days ago Description: Themes for the Blackbox Windowmanager Installations reported by Popcon: 221 cabber (#553902), orphaned 3 days ago Description: Easy and basic jabber console client Installations reported by Popcon: 112 callgit (#553391), orphaned 6 days ago Description: lookup callsigns at qrz.com Installations reported by Popcon: 38 cd5 (#554055), orphaned 3 days ago Description: Compute checksum of individual track on CD-ROMS Installations reported by Popcon: 37 cdtool (#554451), orphaned yesterday Installations reported by Popcon: 996 colormake (#554004), orphaned 3 days ago Description: simple wrapper around make to colorize output Installations reported by Popcon: 556 colrconv (#553393), orphaned 6 days ago Description: Convers client with curses color support Installations reported by Popcon: 19 colrdx (#553395), orphaned 6 days ago Description: DX-cluster client with curses color support Installations reported by Popcon: 27 cwdaemon (#553396), orphaned 6 days ago Description: morse daemon for the parallel or serial port Installations reported by Popcon: 52 cwirc (#553397), orphaned 6 days ago Description: X-Chat morse plugin Installations reported by Popcon: 25 dangen (#554249), orphaned 2 days ago Description: shoot 'em up game where accurate shooting matters Installations reported by Popcon: 133 flex-old (#553704), orphaned 4 days ago Installations reported by Popcon: 223 gcb (#553654), orphaned 4 days ago Description: Utility to calculate long and short path to a location Installations reported by Popcon: 44 ghextris (#553486), orphaned 5 days ago Description: A Tetris-like game on a hexagonal grid Installations reported by Popcon: 166 giftoxic (#553349), orphaned 6 days ago Description: GTK2 based GUI for the giFT filesharing system Installations reported by Popcon: 114 glfer (#553655), orphaned 4 days ago Description: program for reception and transmission of QRSS/DFCW signals Installations reported by Popcon: 33 gmanedit (#553984), orphaned 3 days ago Description: GTK+ man pages editor Installations reported by Popcon: 101 googlizer (#554674), orphaned today Description: utility to search Google via your GNOME menu/panel Installations reported by Popcon: 293 gpsk31 (#553657), orphaned 4 days ago Description: A gtk based psk31 Installations reported by Popcon: 51 grandfatherclock (#554250), orphaned 2 days ago Description: a clock that tolls time acoustically Installations reported by Popcon: 112 grig (#553658), orphaned 4 days ago Description: graphical user interface to the Ham Radio Control Libraries Installations reported by Popcon: 49 gtk2-engines-cleanice (#553506), orphaned 5 days ago Description: CleanIce themes for GTK+ 2.x Installations reported by Popcon: 1057 gtk2-engines-magicchicken (#553505), orphaned 5 days ago Description: Magic Chicken themes for GTK+ 2.x Installations reported by Popcon: 838 happydigger (#553982), orphaned 3 days ago Description: Program for cataloging for archaeological finds Installations reported by Popcon: 9 ibp (#553985), orphaned 3 days ago Description: Viewer for the International Beacon Project Installations reported by Popcon: 33 libpano12 (#554056), orphaned 3 days ago Description: panorama tools library development files Reverse Depends: libpano12-bin libpano12-dev Installations reported by Popcon: 409 makeztxt (#553459), orphaned 5 days ago Description: Create zTXT databases from ASCII files to read them in a Palm Installations reported by Popcon: 46 marote (#553989), orphaned 3 days ago Description: Rig Control Program for the Elecraft K2 Installations reported by Popcon: 11 minimuf (#553990), orphaned 3 days ago Description: program to predict high frequency propagation data Installat
Re: Bug#554694: FTBFS with binutils-gold
reassign 554694 qt4-qmake retitle 554694 qt4-qmake generates a makefile which is incompatible with binutils-gold thanks Hi, Peter. Goldendict are built by qt4-qmake. I think that You should report about such projects in qt4-qmake package, because just qt4-qmake generates linker call command. I think that it is the same as packages which are under automake/autoconf. You buried me with the same bugs, but only one really touched my package. I think You should find out which specific a package has a bug before submit bugreports. For example: fluxbox is built with autotools. goldendict is built with qt4-qmake. Do You suggest me to patch all these packages? On 00:31 Fri 06 Nov , Peter Fritzsche wrote: PF> Source: goldendict PF> Version: 0.9.0+svn404-1 PF> Severity: minor PF> User: peter.fritzs...@gmx.de PF> Usertags: no-add-needed PF> Tried to build your package and it fails to build with GNU binutils-gold. The PF> important difference is that --no-add-needed is the default behavior of of GNU PF> binutils-gold. Please provide all needed libraries to the linker when building PF> your executables. PF> More informations can be found at PF> http://wiki.debian.org/qa.debian.org/FTBFS#A2009-11-02Packagesfailingbecausebinutils-gold.2BAC8-indirectlinking PF> g++ -Wl,-O1 -o goldendict build/folding.o build/main.o build/dictionary.o build/config.o build/sources.o build/mainwindow.o build/utf8.o build/file.o build/bgl_babylon.o build/bgl.o build/initializing.o build/article_netmgr.o build/dictzip.o build/btreeidx.o build/stardict.o build/chunkedstorage.o build/xdxf2html.o build/iconv.o build/lsa.o build/htmlescape.o build/dsl.o build/dsl_details.o build/filetype.o build/fsencoding.o build/groups.o build/groups_widgets.o build/instances.o build/article_maker.o build/scanpopup.o build/articleview.o build/externalviewer.o build/wordfinder.o build/groupcombobox.o build/keyboardstate.o build/mouseover.o build/preferences.o build/mutex.o build/mediawiki.o build/sounddir.o build/hunspell.o build/dictdfiles.o build/audiolink.o build/wstring.o build/wstring_qt.o build/processwrapper.o build/hotkeywrapper.o build/hotkeyedit.o build/langcoder.o build/editdictionaries.o build/loaddictionaries.o build/transliteration.o build/romaji.o build/russiantranslit.o build/german.o build PF> /website.o build/orderandprops.o build/language.o build/dictionarybar.o build/broken_xrecord.o build/history.o build/atomic_rename.o build/articlewebview.o build/zipfile.o build/indexedzip.o build/moc_mainwindow.o build/moc_dictionary.o build/moc_config.o build/moc_sources.o build/moc_initializing.o build/moc_article_netmgr.o build/moc_groups.o build/moc_groups_widgets.o build/moc_article_maker.o build/moc_scanpopup.o build/moc_articleview.o build/moc_externalviewer.o build/moc_wordfinder.o build/moc_groupcombobox.o build/moc_mouseover.o build/moc_preferences.o build/moc_mediawiki.o build/moc_hotkeywrapper.o build/moc_hotkeyedit.o build/moc_editdictionaries.o build/moc_loaddictionaries.o build/moc_orderandprops.o build/moc_dictionarybar.o build/moc_history.o build/qrc_resources.o build/qrc_flags.o-L/usr/lib -lvorbisfile -lvorbis -logg -lz -lhunspell-1.2 -lXtst -lQtWebKit -lQtXml -lQtGui -lQtNetwork -lQtCore -lpthread PF> /usr/bin/ld: build/keyboardstate.o: in function KeyboardState::checkModifiersPressed(int):keyboardstate.cc:33: error: undefined reference to 'XkbGetState' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::ungrabKey(std::_Rb_tree_const_iterator >):hotkeywrapper.cc:481: error: undefined reference to 'XUngrabKey' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::grabKey(unsigned int, unsigned int):hotkeywrapper.cc:473: error: undefined reference to 'XGrabKey' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::init():hotkeywrapper.cc:305: error: undefined reference to 'XKeysymToKeycode' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::init():hotkeywrapper.cc:306: error: undefined reference to 'XKeysymToKeycode' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::init():hotkeywrapper.cc:308: error: undefined reference to 'XKeysymToKeycode' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::init():hotkeywrapper.cc:309: error: undefined reference to 'XKeysymToKeycode' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::init():hotkeywrapper.cc:321: error: undefined reference to 'XOpenDisplay' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::init():hotkeywrapper.cc:350: error: undefined reference to 'XSync' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::init():hotkeywrapper.cc:330: error: undefined reference to 'XCloseDisplay' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::init():hotkeywrapper.cc:344: error: undefined reference to 'XFree' PF> /usr/bin/ld: build/hotkeywrapper.o: in function HotkeyWrapper::init()
Re: binutils-gold and symbols files
On Fri, Nov 06, 2009 at 12:44:31AM +0100, Michael Biebl wrote: > As I received a couple of bug reports today about packages FTBFS, I installed > binutils-gold and tried to compile a few of my packages with it. > > What I noticed is, that every package with symbols file, produced a lintian > error, as binutils-gold added new symbols, the most common one was > e...@base > > What's the reason for those additional symbol(s) with binutils-gold? Corollary: can't they be hidden ? Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: binutils-gold and symbols files
On Fri, 06 Nov 2009, Mike Hommey wrote: > On Fri, Nov 06, 2009 at 12:44:31AM +0100, Michael Biebl wrote: > > As I received a couple of bug reports today about packages FTBFS, I > > installed > > binutils-gold and tried to compile a few of my packages with it. > > > > What I noticed is, that every package with symbols file, produced a lintian > > error, as binutils-gold added new symbols, the most common one was > > e...@base > > > > What's the reason for those additional symbol(s) with binutils-gold? > > Corollary: can't they be hidden ? If necessary, they can be blacklisted by dpkg-gensymbols, it already does that for a couple of internal symbols that the toolchain does add automatically. Please file a wishlist bug against dpkg-dev with the list of symbols in that case. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
