Re: File Versioning for the KDE Desktop...
On 2024-10-04, Andrey Rakhmatullin wrote: >> * KDE has a *requirement* that .desktop files be executable > > Does it? No. But it is a requirement for .desktop files in nonstandard locations for launching them to work. (so that you don't download a .desktop file and double click it to launch it) /Sune
Re: dh-cmake writing to /usr instead of fakeroot?
On 2024-02-19, Elliana May wrote: > You can see a failure here: > https://launchpadlibrarian.net/714820377/buildlog_ubuntu-jammy-arm64.duckdb_0.10.0_BUILDING.txt.gz That build log is pointing to a missing debhelper build-dependency. /Sune
Re: Bug#1052597: RFS: libkysdk-base/2.2.0.1-1 -- common files for kylin sdk base library
On 2023-12-18, Tobias Frost wrote: > - Updating the SONAME of a library requires this procedure to be followed: > https://wiki.debian.org/Teams/ReleaseTeam/Transitions > Comparing the symbols file does not make it obvious why you are > bumping SONAME, but I did not check with abi-complicance-checker... > Can you fill me in why you bump the soname? > > - the breaks/replaces version seems odd, as it is a binnmu version. > You likely want (<< 2.2.0.1-1~), though I am not sure why you think > you'll need the Break/Replace? Can you exand? > > - you could use d/clean instead of overriding dh_clean > > - for the install files, for multiarch, a cleaner way would be to write > /usr/lib/${DEB_HOST_MULTIARCH}/… instead of /usr/lib/*/… Why does the build system force an ancient c++ standard ? It seems to mostly get in the way and there are rarely good reasons to do it. Why does it build with -O1 in release mode ? How do you plan on dealing with just a SONAME break in one of the libraries? Why is nlohman-json embedded and not used from system? - Also just a quick review. /Sune
Re: Help with catch2 transition needed
On 2023-11-07, Andreas Tille wrote: > I noticed that catch2 does not contain the header file catch.hpp any > more. There is now some catch_all.hpp. So I replaced this header file > in a patch[1] but obviously this problem can't be solved by pure wild > guessing since this has lead to > >/usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/Scrt1.o: in > function `_start': > (.text+0x17): undefined reference to `main' in catch2 3.0 and later you now need to link catch2 and catch2 main in your tests. try link with Catch2WithMain in your test targets Like this: target_link_libraries(test PRIVATE Catch2::Catch2WithMain) /Sune
Re: Bug#1053662: RFS: qt5-ukui-platformtheme/4.1.0.1-1 -- Qt5 QPA platform theme of UKUI
On 2023-10-08, xibowen wrote: > * URL : https://gitee.com/openkylin/qt5-ukui-platformtheme I think we should try to not add more c++ code that forces ancient c++ standards in their build systems. /Sune
Re: How to handle breakages when the size of a class in a shared lib increases?
On 2023-07-11, Pierre Gruet wrote: > Unfortunately, it turns out fields were added to some class (of which > size thus increased) in the shared library, so that binaries built > against a previous version of it now segfault as they are not allocating > enough space. Either you need to do a packagename change (and debian specific SONAME iwth all that entails; or maybe there is a way to restore the old abi. Can you provide a full diff of header,implementation of the relevant classes ? /Sune
Re: Bug#923209: RFS: heaptrack/1.1.0+20180922.gitf752536-3.1 [NMU]
On 2019-02-25, Chris Lamb wrote: > Hi Nicholas, > >> heaptrack (1.1.0+20180922.gitf752536-3.1) unstable; urgency=medium >> >> * Non-maintainer upload. >> * Update description to make heaptrack more discoverable to users. >> (Closes: #915241) >> >> -- Nicholas D Steeves Sun, 24 Feb 2019 19:44:03 -0700 > > Whilst I agree about the poor visibility I don't think this > warrants a non-maintainer upload (or even a "normal"-level > severity…) especially during a freeze so I will not be sponsoring > this upload. Apologies. Maybe the fact that heaptrack-gui doesn't depend on either heaptrack nor libheaptrack might be a rc bug. and maybe this can be sneaked in ? :) /Sune
Re: Bug#920218: RFS: webcamoid/8.5.0+dfsg-1
On 2019-01-22, Herbert Fortes wrote: > akqml - full featured webcam capture application - qml module shouldn't this be called qml-module-something instead ? > libavkys-dev - full featured webcam capture application - dev Who are the consumers/users of this ? > webcamoid-plugins - full featured webcam capture application - plugins And this? /Sune
Re: cmake issue with minia: include could not find load file (GatbCore)
On 2019-01-21, Andreas Tille wrote: > Is there any way to make cmake more verbose where it is seeking for files > to include? cmake --trace at least give you more debugging info than you could ever wish for. /Sune
Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3
On 2019-01-09, Andrey Rahmatullin wrote: > As usual: reading the code, debugging, printfs. Address sanitizer and/or > valgrind may or may not help too. I just tried throwing some tools at it. Apparantly you need a three step thing to get to it. address-sanitizer. First issue. The command to create the test data to get the error. $ ./ffindex_build -s ./test.data ./test.ffindex test/data test/data2 = ==824==ERROR: LeakSanitizer: detected memory leaks Direct leak of 304 byte(s) in 1 object(s) allocated from: #0 0x7f3393888ed0 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0) #1 0x7f33937994f1 in ffindex_index_parse /home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:325 #2 0x56072c890783 in main /home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex_build.c:243 #3 0x7f33935f9b16 in __libc_start_main ../csu/libc-start.c:310 SUMMARY: AddressSanitizer: 304 byte(s) leaked in 1 allocation(s). Oh well. rebuild without address sanitizer and run the first two steps. Then rebuild with address sanitizer for the last step. $ ./ffindex_modify -u ./test.ffindex b AddressSanitizer:DEADLYSIGNAL = ==1453==ERROR: AddressSanitizer: SEGV on unknown address 0x000ca3ff8001 (pc 0x7f459600a9f7 bp 0x7ffd6674b8d0 sp 0x7ffd6674b8a0 T0) ==1453==The signal is caused by a READ memory access. #0 0x7f459600a9f6 in action /home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:554 #1 0x7f45960076ed in trecursemisc /home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:26 #2 0x7f459600775d in trecursemisc /home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:31 #3 0x7f4596007827 in twalkmisc /home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:44 #4 0x7f459600aac3 in ffindex_tree_write /home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:563 #5 0x7f4596009f60 in ffindex_write /home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:443 #6 0x55c8564c3fa8 in main /home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex_modify.c:182 #7 0x7f4595e69b16 in __libc_start_main ../csu/libc-start.c:310 #8 0x55c8564c3259 in _start (/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/build/src/ffindex_modify+0x2259) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:554 in action ==1453==ABORTING I'm not sure that gives more new info. Lets try valgrind. $ valgrind ./ffindex_modify -u ./test.ffindex b ==32176== Memcheck, a memory error detector ==32176== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==32176== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==32176== Command: ./ffindex_modify -u ./test.ffindex b ==32176== ==32176== Invalid read of size 8 ==32176==at 0x4846525: trecursemisc (twalkmisc.h:25) ==32176==by 0x484658E: trecursemisc (twalkmisc.h:31) ==32176==by 0x4846633: twalkmisc (twalkmisc.h:44) ==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563) ==32176==by 0x48477C2: ffindex_write (ffindex.c:443) ==32176==by 0x10985E: main (ffindex_modify.c:182) ==32176== Address 0x4a536e1 is 17 bytes inside a block of size 24 alloc'd ==32176==at 0x483577F: malloc (vg_replace_malloc.c:299) ==32176==by 0x4986160: tsearch (tsearch.c:338) ==32176==by 0x4847C02: ffindex_index_as_tree (ffindex.c:533) ==32176==by 0x1094D7: main (ffindex_modify.c:122) ==32176== ==32176== Invalid read of size 8 ==32176==at 0x4847C6D: action (ffindex.c:554) ==32176==by 0x4846543: trecursemisc (twalkmisc.h:26) ==32176==by 0x484658E: trecursemisc (twalkmisc.h:31) ==32176==by 0x4846633: twalkmisc (twalkmisc.h:44) ==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563) ==32176==by 0x48477C2: ffindex_write (ffindex.c:443) ==32176==by 0x10985E: main (ffindex_modify.c:182) ==32176== Address 0x4a53d is not stack'd, malloc'd or (recently) free'd ==32176== ==32176== ==32176== Process terminating with default action of signal 11 (SIGSEGV) ==32176== Access not within mapped region at address 0x4A53D ==32176==at 0x4847C6D: action (ffindex.c:554) ==32176==by 0x4846543: trecursemisc (twalkmisc.h:26) ==32176==by 0x484658E: trecursemisc (twalkmisc.h:31) ==32176==by 0x4846633: twalkmisc (twalkmisc.h:44) ==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563) ==32176==by 0x48477C2: ffindex_write (ffindex.c:443) ==32176==by 0x10985E: main (ffindex_modify.c:182) ==32176== If you believe this happened as a result of a stack ==32176== overflow in your program's main thread (unlikely but ==32176== possible), you can try to increase the size
Re: Help to get Qt GUI of clonalorigin needed
On 2017-12-03, Andreas Tille wrote: > code from Qt4 to Qt5[2] which enabled to **build** the package. The patch looks right for a start. > $ clonalorigin-gui > QMetaObject::connectSlotsByName: No matching signal for > on_actionGelman_Rubin_test_activated() connectSlotsByName is unfortunately one of the misfeatures where it ist attempted to magically by function name tie things together. I think you need to go thru all of this manually and create connect statements where they are needed. Or figure out if some of your objects haven't set an object name. In general, void on__(); is what is looked for in the automatching. http://doc.qt.io/qt-5/qmetaobject.html#connectSlotsByName is the documentation. /Sune
Re: Bug#809768: RFS: kbibtex/0.6+git7fdc0cd97c093f-1
On 2016-01-03, Bastien ROUCARIÈS wrote: Hi A brief look over it: > dget -x > http://mentors.debian.net/debian/pool/main/k/kbibtex/kbibtex_0.6+git7fdc0cd97c093f-1.dsc There is a patch to the desktop file. Where is it forwarded to ? Has it been merged? kdelibs5-dev is qt4 based. No need in build-deps. QT_SELECT should not be needed with cmake build system The dir to symlink thing. Is that really needed? what's the gain? ANd isn't it going to be a mess if you want to transition away from it? Also note that libqxt is more or less dead, so waiting for a qt5 edetion is likely never going to happen. If I was upstream of kbibtex I'd just clean up the single widget and strip all the bits I didn't need and keep maintaining my own version of that. There is likely other minor issues here and there, but I'll let others look for them. /Sune (I'm not planning to sponsor it, amongst other reasons because I have no clue what the application does)
Re: sponsor/mentor packaging advise.
On 2014-07-17, Scarlett Clark wrote: > Hello! > I have been doing alot of packaging over at Kubuntu and enjoy it thoroughly. > I am seeking assistance in getting bits over into Debian as requested. With > that said I have been requested to get packaging for I've over irc adviced Scarlett to get in contact with the last uploader (Mark Purcell) - and if he isn't availablee I'll likely be around and I'm coincidentally a member of the mainatinance team. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lq9fd4$to1$1...@ger.gmane.org
Re: Help with libquazip / Qt4-Qt5
On 2014-07-14, Eric Maeker wrote: >>> Please, Mentors, help me with these unlying questions. >>> - should libquazip be build inside debian using Qt5 and/or Qt4? >> >>Both. for now. > > Ok. How can I manage this? Is it possible inside one unique source > package? Debhelper does only have a qmake_qt4 buildsystem. I don't think dh(1) supports two build sets, so you will have to do it manually. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lq0ocm$iap$1...@ger.gmane.org
Bug#753898: RFS: Looking for sponsor for apg-gui
On Saturday 05 July 2014 23:36:12 Tymon Radzik wrote: > I have just uploaded to mentors my package - it is called apg-gui and is > complex Graphical User Interface for Automated Password Generator. It > supports all it functions. I have made it in C++ Qt. I think it should be > put into Debian archive, because: I think - after a quick browse over the upstream source code, that the project isn't yet ready to be shipped by Debian. Some of the initial issues I noted in the first file I looked at: |int n,m,sx,a; |QString mode, exclude, salt; These looks like they are treated as class members. Please make them class members rather than file local variables. The variable names also is kind of ... brief. |std::string Scores::exec(char* cmd) { |FILE* pipe = popen(cmd, "r"); |if (!pipe) return "ERROR"; Using 'magic strings' instead of enums usually makes code harder to understand |char buffer[128]; |std::string result = ""; |while(!feof(pipe)) { |if(fgets(buffer, 128, pipe) != NULL) |result += buffer; |} |pclose(pipe); |return result; |} Try look into using QProcess instead of trying to do process handling by hand. |ui->progressBar->setValue(5); progressBar looks like a autogenerated value. Please use descriptive variable names. |std::string wyniki = std::string("apg -q -n ") + std::to_string(n) + " -m | " + std::to_string(m) + " -x " + std::to_string(sx) + " -a " + | std::to_string(a); Instead of playing hard-to-read scrabble with the strings, try use some simpler substitution pattern, maybe even QString, since you have it handy and use it already. But given this is to be passed on to a process handling tool, putting every component seperately in a QStringList and then handing it off to QProcess could improve the readability. |if(exclude != "") wyniki+=" -E " + exclude.toStdString(); Try use the empty/isEmpty function rather than comparing to the empty string. |char *cstr = new char[wyniki.length() + 1]; |strcpy(cstr, wyniki.c_str()); Where is cstr free'd ? | void Scores::on_pushButton_clicked() what's the pushButton ? | void Scores::on_pushButton_2_clicked() What's pushButton_2 And the body of this function has all the same issues as mentioned in the ctor, including the unhandled memory. /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5703829.bzaENFAitk@dabney
Re: Help with libquazip / Qt4-Qt5
On 2014-06-13, Eric Maeker wrote: > Please, Mentors, help me with these unlying questions. > - should libquazip be build inside debian using Qt5 and/or Qt4? Both. for now. > - for Qt4 projects (as some projects still not ported to Qt5), how can > we provide a compatible Qt4 libquazip? > * Should I manage two binairies: libquazip1-qt4{-dev}, > libquazip1-qt5{-dev}? Yes. > * Should I create a default sym link to Qt5 version > (libquazip.so.1.0.0 -> libquazip1-qt5.so.1.0.0)? this can lead to > conflicts? No. if there is a defalut, it should currently be qt4. It also ensures that existing things to work. > * Is there a way for users to be correctly linked to the compatible Qt > version (without any user's code modification)?=20 People have to be specific with doing a qt4 or qt5 quazip. /Sune - one of the debian qt/kde packagers -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lnhllq$e3p$1...@ger.gmane.org
Re: grokking debian symbols files
On 2014-04-04, Jakub Wilk wrote: > It's a pkgkde-symbolshelper(1)'s (from the pkg-kde-tools package) thing. > But AFIACS pkgkde-symbolshelper doesn't have any documentation, so the > “is not explained” still holds. :/ http://pkg-kde.alioth.debian.org/symbolfiles.html > Hopefully it's a matter of updating > perllib/Debian/PkgKde/SymbolsHelper/Substs/TypeSubst.pm, as it doesn't > seem to support arm64 yet. That file likely needs to be updated for new archs, yes. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lhlos1$erq$1...@ger.gmane.org
Re: Help with d-shlibs needed
On 2014-04-03, Andreas Tille wrote: > Hi, > > I tried to migrate bamtools (not yet released package!) at > >git://anonscm.debian.org/debian-med/bamtools.git > > to d-shlibs but it ended up by What's d-shlibs and why do you use it? Isn't it just much easier to use a install file pointing the right places? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lhjjnu$b38$1...@ger.gmane.org
Re: Solving shlibs-declares-dependency-on-other-package lintian warning
On 2014-03-18, Joseph Herlant wrote: > The complete version of the packages are currently available on > mentors (for those who would like to have a look a little deeper about > what's wrong): > https://mentors.debian.net/package/libnxml > and > https://mentors.debian.net/package/libmrss > > The warning messages I have are: > > W: libnxml0: shlibs-declares-dependency-on-other-package libnxml0, > libnxml-abi- > > W: libmrss0: shlibs-declares-dependency-on-other-package libmrss0, > libmrss-abi- Who provides those -abi- packages ? Sounds like you are into teh kind of magic that takes a week to explain on a level where -mentors fit in. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lgaebh$du$1...@ger.gmane.org
Re: missing symbols for non-public functions in library?
On 2014-03-04, Sascha Steinbiss wrote: > developers -- of which I am one). This now leads to a discrepancy > involving missing symbols, apparently detected by comparison to the > 1.5.1 symbols file created by Andreas quite some time ago for me (thanks > btw!). According to the policy, this is a condition which normally calls > for an ABI version bump :( If the symbols aren't available in public headers, then just move on without changing the ABI versioning. > However, only two of the missing symbols appeared in public API headers > distributed in the 1.5.1 libgenometools0-dev package. This luckily makes But there are apparantly two symbols ... > been mistakenly exported are changed), is it OK to add wrappers for > those which are in the official API, and to simply adjust libtool to not Yes. If people use symbols not available thru the public headers, they get to keep the pieces. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lf51og$prm$1...@ger.gmane.org
Re: Is this really the debian way ?
On 2014-02-08, Roelof Wobben wrote: > DEB_DH_MAKESHLIBS_ARGS_libcjs0c = -Xusr/lib/cjs-1.0/ -V'libcjs0c (>= > $(DEB_UPSTREAM_VERSION)), libcjs0-$(LIBMOZJS)' -- -c4 I don't see anything wrong here. It is not in the 'beginners end' of library packaging, and library packaging is not in the 'beginners end' of packaging. The more complex the libraries, the more complex you often need to be in your rules file. In this case, it ensures that anything that links libcjs0c ensures that it is installed along with the libcjs0-$(LIBMOZJS) package. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ld85p2$hdn$1...@ger.gmane.org
Re: Bug#736355: RFS: checkbox-ng/0.1-1 [ITP] -- Simple replacement for CheckBox
On 2014-01-22, Sylvain Pineau wrote: > It builds those binary packages: > > checkbox-ng - Simple replacement for CheckBox What's CheckBox? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/lboubh$l4p$1...@ger.gmane.org
Bug#718893: RFS: coinutils/2.9.4-1 [ITA] -- CoinOR base library
On Wednesday 07 August 2013 15:45:37 Etienne Millon wrote: > There are tarballs containing the full distribution at: > http://www.coin-or.org/download/source/CoinAll/ > > It seems to be a a little older (the last release is from january > 2012), but it would be massively easier to maintain than having N > source packages. What do you think? In the general case, it is normally much easier to maintain N smaller packages than one giant that combines everything. It makes 'release early, release often' much simpler since you can just push a fix to e.g. coinutils without having to also push a fix to cgl, cbc and others. Like the bugfix I pushed to cbc: http://packages.qa.debian.org/c/coinor-cbc/news/20110701T100215Z.html - much simpler just to push that than to push a entire new CoinAll. And in this specific case, the coinor build systems in general is so full of weirdnesses that just adapting it in smaller bits is much more feasable than adapting all of it. And given the different parts of coinor also have different release schedules it is also easier to provide the actual newest fixed bits with separate packages rather than large combined packages. So from my experience, both with coinor and with other large source packages, (KDE*, Qt*), separate sources is just the thing to do. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5399456.B9PKAJJzXg@gladstone
Re: I'm so frustrated trying to adopt a package, I could scream.
On 2013-02-12, Paul Johnson wrote: > Can I guess what's next? 664092 is a bug against the metapackage wnpp. > So my message is supposed to be: > package wnpp > retitle 664092 ITA: blt -- the BLT extension library for Tcl/Tk - > run-time package > owner 664092 pauljoh...@freefaculty.org yes. the 'package' statement is optional and describes what package the bug is reported against. in this case, the pseudopackage wnpp. One of the primary purposes of 'package' is to help avoiding typos and such like retitle 12345 eats data for lunch severity 12346 serious owner 12345 ! thanks (note the typo in the second line that would have touched a different bug than what I meant) /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkhl5c9.me.nos...@sshway.ssh.pusling.com
Re: Maintainer address for collab-maint team maintained packages
On 2012-11-19, Arno Töll wrote: > That said, I'd be very glad to have some mailing list Debian service > different to lists.d.o for such lightweight list management purposes. wasn't there a teams.dn ? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkal18a.me.nos...@sshway.ssh.pusling.com
Re: Bug#669565: RFS: gammaray/1.1.0-1 [ITP] -- Tool for examining the internals of Qt application
On 2012-08-10, Felix Geyer wrote: > On 10.08.2012 16:47, Jakub Adam wrote: >>> debian/patches/gammaray-probe-versioned-soname.patch: >>> >>> Why do you set a SONAME for gammaray_probe? >>> When gammaray changes the ABI custom plugins will break anyway >>> since you can't install different versions of gammaray. >> >> When SONAME is not set, lintian produces these warnings and error: >> >> W: gammaray: dev-pkg-without-shlib-symlink usr/lib/gammaray_probe.so >> usr/lib/gammaray_probe.so >> W: gammaray: shlib-without-versioned-soname usr/lib/gammaray_probe.so >> gammaray_probe.so >> E: gammaray: postinst-must-call-ldconfig usr/lib/gammaray_probe.so >> >> So the right solution is to override the warnings and add ldconfig call into >> postinst script by hand? > > Maybe a better solution would be to set the SONAME to the upstream version > number. > That way it's explicit that plugins need to be recompiled when the upstream > version > changes. whattabout just not offer -dev stuff for gammaray until there is actually a need for it? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnk2ga51.ut3.nos...@sshway.ssh.pusling.com
Re: Bug#674717: RFS: qpdfview/0.2.2-1 [ITP]
On 2012-05-26, Benjamin Eltzner wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "qpdfview" > > * Package name: qpdfview >Version : 0.2.2-1 >Upstream Author : Adam Reichold > * URL : https://launchpad.net/qpdfview > * License : GPL-3 >Section : graphics > > It builds those binary packages: > > qpdfview - tabbed PDF viewer Please note for potential sponsors that this app is licensed as gplv3 and it uses poppler still at gplv2only. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjs2skr.p7v.nos...@sshway.ssh.pusling.com
Re: Bug#672268: RFS: kde-gtk-config/2.0-1 [ITP] -- KDE configuration module for GTK+ 2.x and GTK+ 3.x style selection
On 2012-05-11, Boris Pek wrote: > kde-config-gtk-style does not allow to: > * select themes for Gtk 3.x applications > * preview available themes for Gtk 2.x and Gtk 3.x applications > * custmize toolbars and menus for Gtk applications > * select icon themes for Gtk applications > * download and apply Gtk 2.x and Gtk 3.x themes from http://opendesktop.org/ > in few mouse clicks > > All these things can be done in kde-gtk-config. what about the following plan then: talk with the kde-config-gtk-style maintainers (kde-extras team and didier raboud) wether it makes sense to just let your package take over the kde-config-gtk-style name. It doesn't look like the current utility does something "your" utility doesn't, am I right? No need to have two tools with the same dependencies, same audience and one tool just does a subset of the other. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjqqm8u.p7v.nos...@sshway.ssh.pusling.com
Re: Bug#672268: RFS: kde-gtk-config/2.0-1 [ITP] -- KDE configuration module for GTK+ 2.x and GTK+ 3.x style selection
On 2012-05-09, Boris Pek wrote: > My regular sponsor is very busy now and I am looking for a sponsor for my new > package "kde-gtk-config". > Description : KDE configuration module for GTK+ 2.x and GTK+ 3.x style > selection first, kde configuration modules are packaged as kde-config-foo second, what does it do that kde-config-gtk-style doesn't do ? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjqqdhb.p7v.nos...@sshway.ssh.pusling.com
Re: Help needed to fix gcc 4.7 bug in jellyfish package
On 2012-05-02, Andreas Tille wrote: > Hi, > > I tried to fix the problem in the jellyfish package but the general > hints given did not helped me really. Any more precise help to fix > this problem: > > parse_dna.cc:97:3: error: narrowing conversion of '-3' from 'int' to 'const > uint_t {aka const long unsigned int}' inside { } is ill-formed in C++11 > [-Werror=narrowing] > > --- jellyfish.orig/jellyfish/parse_dna.cc > +++ jellyfish/jellyfish/parse_dna.cc > @@ -57,7 +57,7 @@ It looks like you aren't the right place. It complains about line 97 and you have edits in line 60 ? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjq1op2.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: owncloud 2.0.1
On 2012-01-01, Thomas Müller wrote: [about a non-free file] > Or wget'ing it within postinst? erm ?!? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjg1mrq.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: qastools
On 2011-12-14, Sebastian H. wrote: > I've made a quick build. > > qastools-common_0.16.1-1_all.deb 23988 bytes > qastools-qasconfig_0.16.1-1_amd64.deb 61768 bytes > qastools-qashctl_0.16.1-1_amd64.deb 274986 bytes > qastools-qasmixer_0.16.1-1_amd64.deb 309520 bytes > > versus > > qastools_0.16.1-1_amd64.deb 651262 bytes My conclusion here would be to not split. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjehbo7.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: qastools
On 2011-12-13, Benoît Knecht wrote: > So? It's difficult for me to get your point when you're asking questions > without making any statement. I'd be grateful if you could clarify. Hi Depending on the answers, my statements would be different. In general, I see to 'primary' reasons for a package split in a package with kind of related utilities: 1) Some of the utilities are real big 2) Some of the utilities has real big dependencies Each package split does also come with a overhead. And I think based on your answer, the qastools splitting doesn't fully make sense. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjegvf2.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: qastools
On 2011-12-13, Benoît Knecht wrote: > Sebastian H. wrote: >> > Why regroup qasmixer and qasconfig into one package? Wouldn't it be >> > better having them Recommend each other? It doesn't seem like an >> > improvement forcing users to install both tools instead of giving them >> > the choice. But maybe I'm missing something. >> >> The short answer is, it makes package maintenance much easier and >> is less error prone. > > I see the point of having one source package for all the tools, but you > could still make several binary packages from there (as alsa-tools does, > though not for every single utility I must admit). What's the size of these packages? what's their dependencies? A quick look from here looks like they are qtgui apps that uses libasound ? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjef9f5.p7v.nos...@sshway.ssh.pusling.com
Re: Overriding .desktop file with localized version (QasMixer)
On 2011-11-01, Alexander Reichle-Schmehl wrote: > Hi! > > Am 01.11.2011 14:14, schrieb Sebastian H.: > >> In the progress of separating localizations for QasMixer into a separate >> package qasmixer-l10n I've stumbled over the following linitan warning: >> >> W: qasmixer-l10n: desktop-command-not-in-package >> usr/share/applications/qasmixer.desktop qasmixer > [..] >> qasmixer-l10n installs a new version of >> /usr/share/applications/qasmixer.desktop >> with additional localized strings and diverts the original file to >> /usr/share/qasmixer/qasmixer.desktop.no_l10n > > Why? Why not install the desktop file with the localized strings in > with the proper package? > And by keeping the localized desktop file in the same package as the application gives also translated entries in the menu, so that it doesn't say Sound Mixer Qasmixer in a danish environment, but rather Lydmikser Qasmixer (I don't know what Qasmixer is or how it is properly capitalized) The translations in the desktop file is not for the application, but for the desktop shell or window manager or whatever is providing the menu. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnjb0ta3.p7v.nos...@sshway.ssh.pusling.com
Re: flashcache - call for resolution / seeking for a mentor
On 2011-09-21, onlyjob wrote: > * Is it true that whoever happen to create an ITP first gets the > monopoly for packaging? > * If ITP always have priority, aren't we sending a wrong message > for ambitious maintainers who might be tempted to create ITP early in > order >to secure the rights for packaging, disregarding of how close > they are to providing a usable package? There are ways to take over a ITP, also without consent from the owner of the ITP. But it requires unresponsiveness from the owner and early communication from the one who wants to take it over. In this case, Arno always replied within 1 or 2 days. And you didn't try to communicate before you were actually done. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj7jahk.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: gentoo (New upstream version: package already in Debian).
On 2011-09-13, Marc Haber wrote: > On Tue, Sep 13, 2011 at 04:17:12PM +0200, Innocent De Marchi wrote: >> I am looking for a sponsor for my package "gentoo". >> >> * Package name: gentoo >>Version : 0.19.11-1 >>Upstream Author : Emil Brink >> * URL : http://www.obsession.se/gentoo/ >> * License : GPL-2+ >>Section : x11 >> >> It builds those binary packages: >> >> gentoo - Fully GUI-configurable, two-pane X file manager > > I would strongly suggest choosing a different name, due to the > identically named Linux distribution. gentoo the file manager has been in Debian for longer time than the identically named Linux distribution has existed, so I do think it is a bit late to suggest a rename. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj6urq6.p7v.nos...@sshway.ssh.pusling.com
Re: Depends on -dev package
On 2011-08-22, Russ Allbery wrote: > "Bernhard R. Link" writes: >> * Russ Allbery [110822 19:59]: > >>> That's a fascinating point. I have never done that with any -dev >>> package, since essentially every -dev package would require that, which >>> seems rather silly. (There are almost no non-trivial C libraries that >>> don't include standard C headers.) But there's no obvious reason why >>> that shouldn't be required given the current Policy wording. > >> Which wording are you talking about? > > There are not, so far as I know, any exceptions for -dev packages from the > normal requirements for Depends, which say simply: > > The Depends field should be used if the depended-on package is > required for the depending package to provide a significant amount of > functionality. > > and given that C -dev packages are unusable in general without libc6-dev > installed, that would, on the surface, seem to qualify. Should it also depend on a c-compiler and recommend make? :) /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj56oa6.p7v.nos...@sshway.ssh.pusling.com
Re: Compiling Qt translation files
On 2011-06-29, Dmitry Shachnev wrote: > Will it be better if I provide .ts text-format source for translations > and compile them during build? This will add a big build-dependency on > Qt. the Qt linguist tools have recently been split out from the qt dev tools to make it easier to just require those. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj0lsoi.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: kst (updated package)
On 2011-06-28, David Kalnischkies wrote: > btw: Without looking at the source: Architecture dependent symbols are e.g. > all methods with size_t (or its sibling ssize_t) or va_list as parameter. and qreal if kst is what I think it is. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnj0jq3d.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: undo-closed-tabs-button
On 2011-05-26, Arno Töll wrote: > a) Without haing further looked on your package you may want to > reconsider package name and description to something more useful. There might actaully be a naming policy for such addons that one should adhere to. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnittkus.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: haskell-qt
On 2011-05-26, Filip Brcic wrote: > On Wednesday, 25. May 2011. 0.29.07 Sune Vuorela wrote: >> On 2011-05-24, Filip Brcic wrote: >> > libghc6-qt-dev - Haskell bindings for Qt GUI library for GHC >> Is it only bindings for QtGui, or for other parts as well ? > > It binds to all parts. Maybe description could be formulated differently, s= > o=20 > that questions like this are avoided. For example, just Qt (or Qt4) library= >=20 > could be sufficient. "gui library" is definately wrong if it binds everything. Qt4 frameworks or Qt4 Libraries or ... somtehnig like that. And maybe you even want, if possible to split at least the non-dev stuff in a per library package. (so that simple gui apps doesn't pull in sql things, a web engine and ...) > >> > libqws - Haskell bindings for Qt GUI library for GHC >> Is this thing actually called libqws? > > That is helper library that helps bind Haskell with C++. The directory is=20 > called QWS, yet the libraries are called libqtc_{core,gui,network,...}. If = > QWS=20 > stands for something else, then it shouldn't be a problem to rename that=20 > subpackage into something else (like libqtc). please consider splitting it. btw, are the bindings based on the smoke library or ? is it qreal float vs double safe? ... /Sune - clueless about haskell -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnittk1s.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: undo-closed-tabs-button
On 2011-05-26, Ludwin Alduvi Hernández Vásquez wrote: > It builds these binary packages: > undo-closed-tabs-button - This add-on allows you to undo closed tabs via a > toolbar button addon to ? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnittk3f.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: haskell-qt
On 2011-05-24, Filip Brcic wrote: > It builds these binary packages: > libghc6-qt-dev - Haskell bindings for Qt GUI library for GHC Is it only bindings for QtGui, or for other parts as well ? > libqws - Haskell bindings for Qt GUI library for GHC Is this thing actually called libqws? QWS in a Qt context has originalyl been Qt Windowing System, as previously used in Qt for embedded linux. /Sune - one of the cute Debian Qt guys. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnitoc9j.p7v.nos...@sshway.ssh.pusling.com
Re: RFS: libiwtan and iwtan-gui (3rd try)
On 2011-05-18, Marco Cornolti wrote: > It builds these binary packages: > libiwtan - meta-package for the IWTAN Wireless Topology Analyzer library I think I asked it before: whath's the prupose of this binary package? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnit7cm5.p7v.nos...@sshway.ssh.pusling.com
Re: what if upstream provides debian build directory
On 2011-03-18, Harald Dunkel wrote: > Is upstream always right? The general answer here is 'no, upstream is never right, but often they can be educated' (when coming to packaging ideas and such) /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnio7ebq.rvp.nos...@sshway.ssh.pusling.com
Re: Build-Dep: libqtwebkit-dev
On 2011-03-16, Mathieu Malaterre wrote: > http://packages.debian.org/sid/libqtwebkit-dev > > It is only available in: > - unstable > - on amd64/i386 well... that's just a matter of time. > > I need to specify something like: B-D on libqtwebkit-dev only if > libQt4-dev does not provide libqtwebkit-dev libqtwebkit-dev | libqt4-dev (<< 4.7) ? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnio2115.rvp.nos...@sshway.ssh.pusling.com
Re: RFS: libiwtan
On 2011-02-23, Marco Cornolti wrote: > Dunno actually. Mainly because dh_make made it for me, so I thought it > was the way things are done. Isn't it needed to keep libiwtan up to date > even when libiwtan0 moves to libiwtan1? well.. who needs a library? the apps dependencies should be enough to keep things updated. > > Anyway, I've deleted it and renamed libiwtan0 to libiwtan. This is wrong. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniml8hr.rvp.nos...@sshway.ssh.pusling.com
Re: RFS: libmk4-2
On 2011-02-24, roucaries bastien wrote: >> Do you intend to maintain this library in Debian if/after this fix for >> akregator is uploaded? > > I will made the fix myself. It is a medium term fix. Long term fix it > to reimplement akregator using akonadi but it a huge work (see kmail). > I plan to maintain metakit until fixed akregator go removed to old > stable. > > akragator use a embeded copy of metakit and I plan to use the so lib > instead of static linking. We have been carefully diffing your metakit with the metakit shipped by Akregator, and have a hard time seeing what fix you have made, and what it is supposed to do. If you can enlighten us, and convince us about the fix, we can add the patch to akregator. As far as I can see, there is no reason to keep a separate metakit package when the only usage in the archive is in akregator. There is people starting up upstream in finishing the long term fix, and I'm sure they would welcome your help. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnimdv56.rvp.nos...@sshway.ssh.pusling.com
Re: RFS: libiwtan
On 2011-02-23, Marco Cornolti wrote: > * URL : http://iwtan.sourceforge.net > * License : GPL v3 hmm.. gplv3 for a library. kind of aggressive. but well. > It builds these binary packages: > libiwtan - meta-package for the IWTAN Wireless Topology Analyzer library why such meta package? > libiwtan-dev - IWTAN: Wireless Topology Analyzer - development files > libiwtan0 - IWTAN: Wireless Topology Analyzer > > The package appears to be lintian clean. > - dget > http://mentors.debian.net/debian/pool/main/l/libiwtan/libiwtan_0.1-1.dsc > > I would be glad if someone uploaded this package for me. what's with the README.source? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnimadf3.rvp.nos...@sshway.ssh.pusling.com
Re: packaging a new qt application with 2 components
On 2011-02-21, Steven wrote: > What would be the best approach to deal with this? > Note that I'm fairly new at creating Debian packages and developing qt > applications (I do have experience in Java, but not with Debian in > mind). two tarballs is a v3 source format? There is nothing special about it being a Qt thing. > source, as that would make it difficult to contribute back to the > 'kernel' component, which is cross-platform. I manage both components in why is on'ly the kernel component cross platform? and what do you mean by cross platform? Who else would use the kernel (other apps)? is the kernel and the gui released with different schedules or with same schedule? What is the compatibility between gui and kernel? and what things is it? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnim5u7c.rvp.nos...@sshway.ssh.pusling.com
Re: RFS: faenza-icon-theme
On 2011-01-24, Adnan Hodzic wrote: >> btw is this theme specific to GNOME or can it be used with other desktop >> environments? > > Specific for GNOME. Last I looked, it was following the FDO icon spec, so theoretically it would work anywhere that supports that spec. Practically, last I looked, faenza only implemented the bare minimum amount of icons needed to support GNOME (I tested in my Plasma Desktop to see how it looked) (for those interested in icon naming, the way icons is found is basically: 1) application asks for icon foo-bar-baz-quux 3) icon loading code tries to locate foo-bar-baz-quux.{svg,png,...} 2) fails to locate that icon 3) tries to locate foo-bar-baz.{svg,png,...} 4) fails to locate that icon 5) tries to locate foo-bar.{svg,png,...} 6) fails to locate that icon 7) tries to locate foo.{svg,png,...} 8) fails to locate that icon 9) returns a default icon (depending on icon theme it can be the folder symbol, or it can be a questionmark icon or ...) and of course if the icon loading code locates the icon, it will be returned to the application) /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnijt1j0.rvp.nos...@sshway.ssh.pusling.com
Re: RFS: muon
On 2010-12-08, Paul Rufos wrote: > muon - package manager for KDE > muon-dbg - Muon debugging symbols > muon-installer - Utility for browsing, installing, and removing applications > muon-notifier - update notifier for KDE > muon-updater - update manager for KDE > qapt-batch - Batch package manager for KDE How do you package manage people? KDE is people producing software. why not just "graphic package manager" or "graphic package manager built on the KDE Platform" /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnig29oj.rvp.nos...@sshway.ssh.pusling.com
Re: RF[CS]: ubiquity (mozilla extension) in Debian
On 2010-10-26, Gabriele Giacone <1o5g4...@gmail.com> wrote: > On 10/26/2010 04:53 PM, Michael Shuler wrote: >> An existing source name conflict example I found: >> >> libsage2 - Source: sage >> xul-ext-sage - Source: sage-extension >> >> -extension sounds a little cleaner to me. ;) > > I'd like to keep ubiquity, name chosen by upstream. > And it's good because there are no packages named ubiquity in Debian. > > Derivatives can choose their own package names. I think it is generally considered good practice to have a source packaeg just building one binary package to be named the same as the binary package. (Yes, I know I have violated that a couple of times with my own packages) /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrniceeg2.rvp.nos...@sshway.ssh.pusling.com
Re: shlibs and lintian
On 2010-10-11, Zvi Dubitzky wrote: > I am having a package for libraries (several) Speaking as a maintainer who has been having library packages that contained several libraries (Qt, kdelibs, kde4libs, kdepimlibs, kdebase-workspace and ) - we have ended up splitting everything so that 1 library goes in one package. I can only recommend that to others because: - users of your libraries might only use one of them, and thus gets fewer dependencies - if upstream changes ABI of one of the libraries, you can change that one packagename and create a smaller transition - make it easier to manage thinrgs with symbol files rather than shlibs files (and as a side effect you end up without such issues as you are describing) /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnib6mam.rvp.nos...@sshway.ssh.pusling.com
Re: RFS: wacom-source
On 2010-07-13, Taylor LeMasurier-Wren wrote: > --0016364ecb64f571dd048b48701a > Content-Type: text/plain; charset=ISO-8859-1 > > Dear mentors, > > I am looking for a sponsor for my package "wacom-source". > > Package name: wacom-source > Version : 0.8.8-1 > Upstream Author : Ping Cheng > URL : http://linuxwacom.sf.net > License : GPL-2 > Section : misc > > It builds these binary packages: > wacom-dkms - Wacom kernel driver in DKMS format > > The package appears to be lintian clean. > > The upload would fix these bugs: 588946 > > My motivation for maintaining this package is: > The Linux Kernel doesn't support the latest Wacom Bamboo Pen & Touch models. > This package builds a new wacom module using the 0.8.8 linuxwawacom source. > Since it uses DKMS, it will automatically rebuild the module with every > kernel upgrade. Why don't you instead work with the debian kernel people to get the linux kernel updated in debian, rather than work around it like this? /Sune - bamboo owner currently compiling this by hand -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni3pj12.rvp.nos...@sshway.ssh.pusling.com
Re: RFS: snap2 rsync-based backup program with GUI (with Debian source)
On 2010-06-15, Lloyd Standish wrote: > It did not occur to me to check for gtkdialog in Sid (it is available > in Lenny http://packages.debian.org/lenny/gtkdialog). So, until > there is a gtkdialog package in Sid, snap2 cannot run. This is a > great disappointment - I put a lot of effort into this, my first > Debian package. > > I'm sorry I did not check for the dependencies in Sid. I never > imagined that gtkdialog would be left out (so far, anyway). Maybe you could fix it to not use gtkdialog? By reading http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543945 it loosk like gtkdialog is dead upstream, so it should just be let alone. I guess the zenity package is what gtk people uses nowadays. In kde land, there is kdialog. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni1fg7f.rvp.nos...@sshway.ssh.pusling.com
Re: Asking for DMUA: Yes while seeking first sponsor
On 2010-06-15, Paul Wise wrote: > This isn't the only misuse of DMUA that exists, some people set it in > their package instead of asking the sponsor to set it. Others go I guess it is unimportant who exactly writes the lines to debian/control. But the sponsor should definately agree on it being added. (I'm normally not modifying anything in the packages I sponsor, but ask the sponsoree to change things. This includes adding DMUA) /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni1esvf.rvp.nos...@sshway.ssh.pusling.com
Re: A lot of pending packages
On 2010-06-09, Lorenzo De Liso wrote: > Hi all, > > I'm a simple debian contributor: I'm trying to get my work in debian > through a sponsor [1] [2]. The problem is that I'm waiting for a sponsor > since 7 days+ (and not only me, in mentors.debian.net there are 20+ > pending packages) [3]. Why are they in pending status and nobody wants > to upload them? I know, we all are busy with the real life things, but a When I'm sponsoring packages, which happens from time to time, it is normally packages that I somehow have a interest in. I think that many other sponsors feel it the same way. For example, my interests is mostly around KDE, and I really try to avoid python stuff. That kind of rules your two packages out for me. I browsed quickly thru those 20+ packages, and a lot of them hasn't been presented on debian-mentors. If they are just uploaded to mentors.dn and then left silent, then no one with notice. I have also seen discussions in other forums about some of the specific packages not presented on this list, so some people also just use mentors.dn to share the work with their 'normal' sponsors, and do the discussions outside this list, so that's also not a good metric. A recommended strategy is to package some apps that are interesting enough to get some DDs to work with you, and then you can also most likely get them to look at other of your stuff. And another often recommended strategy is to help with existing packages, rather than introducing new. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni1069g.rvp.nos...@sshway.ssh.pusling.com
Re: desktopnova (rename packages or change dependencies?)
On 2010-06-09, Daniel Leidert wrote: > b) Let both modules packages provide desktopnova-module and conflict > with each other. Then let desktopnova depend on desktopnova-module. So > the user will have to choose the module package to install. IMO this is > a common solution. This is definately not a common solution. It prevents user A and user B using desktopnova in different DE's. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni101dg.rvp.nos...@sshway.ssh.pusling.com
Re: RFS: lmfit
On 2010-03-12, j.wuttke wrote: > Dear mentors, > > I am looking for a sponsor for my package "lmfit". > > * Package name: lmfit >Version : 3.1-1 >Upstream Author : myself (Joachim Wuttke > * URL : http://www.messen-und-deuten.de/lmfit/lmfit.html > * License : public domain >Section : libs > > It builds these binary packages: > lmfit - Least-squares minimization and curve fitting > lmfit-dev - Development files for Levenberg-Marquardt library lmfit Hi I haven't yet downloaded the package, but it looks like there is some library packaging basics missing here. Libraries is supposed to be named libsomethingSOVERSION It would be very nice if there was at least some test apps for potential sponsors to see if the library actually works. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhpqpdq.nfa.nos...@sshway.ssh.pusling.com
Re: RFS: libqt4pas
On 2010-01-12, Matthias Klumpp wrote: > This package is necessary to build FPC/LCL Pascal applications against Qt4. > It would make lots of FPC apps able to be compiled for the KDE/Qt platform > and fix some bugs depending on this. > The package was previously known as "libqtintf4" and had some problems > (MOC-files in source-code etc.), which have now been fixed by > upstream. I think it looks much better than what I earlier have seen. Good job to you and upstream. I'm not giving a final review and also not sponsoring it, as pascal is outside my scope, but good luck with finding someone to sponsor it. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: libqtintf4 (ping)
On 2009-12-18, Matthias Klumpp wrote: > The package is lintian-clean. There were some concerns about the > build-script, but because it's a really small lib there should be no > problem in building this. The way it is built, it takes around 1G of memory to build. This *needs* to be fixed. it might be a small lib, but the way it is built is just plain wrong. Especially since this can be easily fixed. The moc output files *must* be regenerated on build, else you end up with issues like: In file included from qtpas.cpp:370: lib/hooks//qwebsettings.cpp_mk:14:2: error: #error "This file was generated using the moc from 4.5.2. It" lib/hooks//qwebsettings.cpp_mk:15:2: error: #error "cannot be used with the include files from this version of Qt." lib/hooks//qwebsettings.cpp_mk:16:2: error: #error "(The moc has changed too much.)" from next Qt upload. and the build script *needs* to be fixed so that it actually fails when build fails. dpatch apply-all applying patch 01_buildscript.patch to ./ ... ok. bash /tmp/libqtintf4-1.72Qt4.5.2/compile_lib.sh Please Modify location of Qt4 in this script touch build-stamp fakeroot debian/rules binary dh_testdir dh_testroot dh_clean -k dh_installdirs dh_install dh_install: libqt4intf5 missing files (libqt4intf.so.*), aborting /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New developer.
On 2009-11-26, George Danchev wrote: > * start with learning how Debian Bug Tracking System is manipulated > (which is one of the most valuable Debian assets) > * look for neglected bug reports, eventually in packages you are using > * try to submit patches and/or helpful comments to these bug reports. > * you might also want to adopt a neglected package, but do so only if > you feel you have the knowledge and time to maintain it properly, not > just for the sake of it. ALternatively, join one of the existing teams that handles some packages you are interested in, and most teams are understaffed. If you are up for big challenges, joining pkg-$your_preferred_desktop_environment could be a possibility. If you are up for even bigger challenges, join the X team. /Sune - member of pkg-kde and looking for someone to package libattica -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: libqtintf4
On 2009-11-10, Matthias Klumpp wrote: > Makefiles just serve to finally create calls to gcc, And I think the way the gcc calls are made requires a amazing amount of RAM for no apparant reason. > these calls I wrote by hand (there was no qmake in qt2) > to more easily configure which Qt to use on the system. > - 2 different Qt's on a system: > The system Qt used to be a Qt3 not so long ago (Debian stable is still > qt3/kde3) > or an old unwanted Qt4 (eg Qt 4.0 and you wanted Qt 4.4) Unimportant what's in debian stable for a package targetted unstable. and erm. talking about Qt2? Qt2 was released in 1999. last Qt2 release was november 2001. Qt3 was released in october 2001, last Qt3 code changing release was march 2007. I'm not sure why this is relevant here. > The binding source is created by scripts, with many manual steps. so the shipped 'source' is not actually 'preferred form of modification'? > A Qt binding is actually always alot of manual work (defining > solutions to every exception, just read the so called typedef > system of QtJambi or a kalyptus generator. kalyptus is the old perl tool used for kdebindings, where there now (for kde4.4 is a newer and better tool) written in c++ using the same parser as used in kdevelop and others. > He will definitely nor re-write the interface using SMOKE (because it is > undocumented and not necessary. Also many applications depend on the > existing libqt4intf). > I dont's see why this package can not be included into Debian. The only > thing which blocks the inclusion is the lack of a make system like qmake, > right? The thing that blocks inclusion is a 'interested sponsor'. I currently maintain a set of bindings, where the smoke based bindings is the one giving me least grief. And I'm not interested in sponsoring things that increases my headaches. > If at least one uses this software, it is relevant for Debian, I think. > Maybe they will switch to SMOKE later, but today the interface library is a > fixed standard if you want to create Qt4 applications with FPC. Do you have > comments on packaging? I haven't gotten to the packaging yet, because there is two things from upstream that *needs* to be fixed. 1) The moc gerenated files *needs* to be generated on build, else the build might break on each new qt version. 2) The build system needs to be done in a way that doesn't kill buildds when it can be avoided. Anyways: Why does it build-depend on libqt4-core ? Why do you chmod +x the compile_lib script when you use bash to run it anyways? How do you make sure the build fails, if the compile_lib script fails? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new-maintai...@debian.org dead?
On 2009-11-07, Harry Rickards wrote: > 2009/11/7 Sune Vuorela : >> On 2009-11-07, Harry Rickards wrote: >>> Hi, >>> >>> I sent an email to new-maintai...@debian.org about a week ago, and >>> haven't received a response yet. It's only been a week, so I'm still >>> hoping to get a reply soon. However, I just found >>> http://lists.debian.org/debian-devel/1999/07/msg01270.html, saying >>> that they're overworked (the OP didn't recieve a reply for over 2 >>> months). That was in '99 tough. Is the situation still the same now >>> (and if so does the documentation need to be updated)? >> >> They are usually quite busy. What did you ask them about? I'm pretty >> sure that 'wrong questions' is of a even lower priority than their real >> tasks. >> >> I did see them act this week on a mail I sent them. >> >> /Sune >> > > I asked about alternative forms of identification for becoming a > Debian Maintainer (*not* a Debian Developer through the New Maintainer > process). it has been discussed a couple of times on the public newmaint list. You can probably find it in the archive. The internet suggests you are british, so I think the easiest thing is to meet up with some DD somewhere in england. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: new-maintai...@debian.org dead?
On 2009-11-07, Harry Rickards wrote: > Hi, > > I sent an email to new-maintai...@debian.org about a week ago, and > haven't received a response yet. It's only been a week, so I'm still > hoping to get a reply soon. However, I just found > http://lists.debian.org/debian-devel/1999/07/msg01270.html, saying > that they're overworked (the OP didn't recieve a reply for over 2 > months). That was in '99 tough. Is the situation still the same now > (and if so does the documentation need to be updated)? They are usually quite busy. What did you ask them about? I'm pretty sure that 'wrong questions' is of a even lower priority than their real tasks. I did see them act this week on a mail I sent them. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: libqtintf4
On 2009-11-07, Matthias Klumpp wrote: > http://users.telenet.be/Jan.Van.hijfte/qtforfpc/fpcqt4.html > * License : GPL Looks like lgpl > It builds these binary packages: > libqt4intf-dev - Qt4 interface bindings > libqt4intf5 - Qt4 interface bindings For which language? > - dget > http://mentors.debian.net/debian/pool/main/l/libqtintf4/libqtintf4_1.72Qt4.5.2-1.dsc The sources seem to contain many autogenerated files with moc. these should be redone on build. How are the bindings done? By manually writing each wrapper class or by some 'secret script' that helps? It looks like the qreal handling is too fragile, but might be just enough to make it work on debian, and it seems to assume that all people using Qt on arm uses 'qtopia'. (qtopia doesn't exist anymore) And wouldn't it make more sense to create different bindings for each qt module? That's what the python, c#, ruby, php, lua, ... bindings are doing. The build system looks like it is a buildd killer. It basically builds all files at once, instead of build all files and then link them together. I'm not sure I like this way of creating qt bindings, I_think doing what the kdebindigs people, by using the 'smoke' intermediate library is a better way ahead. I'm not interested in pascal, so I won't sponsor this. This is a first list of comments from some Qt person ;) /Sune - maintainer of qt, kde, including kde and qt bindings for various languages. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: pidgin-skype
On 2009-11-03, Don Armstrong wrote: > It's fairly rare for someone to laboriously create multiple versions > of icons at different resolutions in PNG. [I know I certainly haven't > done it since about 1992.] Yes and no. Some icon artists create it in svg and then export to png and does pixelmanipulations of each size. What's the source here ? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kwin-style-aurorae
On 2009-10-31, Lukasz Janyst wrote: > Hi there, > > I have been using Debian for a couple of years now. I really > appreciate the great work you're doing and I would like to help. I > have read some docs and faqs on contributing to the project and > decided to start with this simple package that I am using every day on > my Debian machines. The 'debianization' boils down to just two lines > in the rules file, but it's probably still a good exercise to get > familiarized with the process. Could somebody please have a look? Hi I haven't looked at the package itself, but just at aurorae. It looks great, and it has been merged into kde trunk, so it will be part of kde 4.4 being uploaded in the beginning of february. I'm not sure wether it is worth uploading aurorae separately at this time, but if you are interested in kde related packaging, you are welcome to join the KDE team and help with KDE and friends directly. Feel free to drop by on #debian-qt-kde on irc.debian.org and say hi. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: qemu-kvm (kvm)
On 2009-10-16, Felipe Sateler wrote: > On Fri, 2009-10-16 at 21:36 +0200, Giuseppe Iuculano wrote: >> Michael Tokarev ha scritto: >> >> You are trying to hijack kvm, this is not the way to do it appropriately. >> > >> > I'm trying to make it to work. >> > And to my shame, I don't know how to do that in another way. >> > I already support debian users by maintaining the package >> > out of debian. >> >> Simply you can't. >> You can't take over a package that you feel is neglected without the assent >> of >> the current maintainer. > > That is not true. That is precisely the point of a hijacking. The > maintainer has been unresponsive for half a year according to Michael, > so it is perfectly reasonable to attempt a hijack (even if it was not > correctly done). And if Michael Tokarev is who I tihnk he is, he has been very much encouraged on #debian-devel to pursue maintainership of kvm. I'm not personally a user of kvm (yet?), but I do feel perfectly safe with Michael as kvm maintainer. I even think it will be a very big improvement. If just half the clue he shows in #debian-devel is 'not faking', I will be very pleased to see a increased involvement of Michael in Debian. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: script-with-language-extension
On 2009-10-05, Charles Plessy wrote: > I have repened the Policy bug where the renaming policy was decided, and hope > to get it reverted. Don't expect it to happen, but you are free to hope. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: libv8
On 2009-09-06, Rogério Brito wrote: >> - I doubt that many sponsors will be happy DM-Upload-Allowed: yes >>on a NEW package. > > While I understand that you mentioned this regarding a NEW package, I'm > a slightly bit confused about the "best current practices" of the DMUA > field. I would never upload a package that adds DMUA for someone I haven't worked with already. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Requests to sponsor new library packages
On 2009-08-19, Ben Finney wrote: > Sune Vuorela writes: > >> On 2009-08-19, Ben Finney wrote: >> > That's interesting, thank you for that perspective. What do you >> > propose, then, for a maintainer who wants to get a new package into >> > Debian, but that package requires one or more separately-packaged >> > libraries that *also* need to be sponsored into Debian before the >> > ???interesting??? package can go in? >> >> Request sponsorship together. And read up on library packaging. > > Matthew Palmer writes: > >> Put them all into the same (or linked) RFS. > > I obviously wasn't clear on this point: The library package is prepared > *first*, to provide functionality needed by the dependent package. > They're not ready for sponsorship together. What advice then? Make the plan clear that you need this as a part of packaging of "coolapp". > In my case, ???fooapp??? needs ???libbar???, which in turn needs > ???libbaz???. So, > with only a limited amount of time, I work first on ???libbaz???, and that > package is ready for sponsorship before the others. Should I wait until > all three are done ??? an indeterminate amount of time ??? before making an > RFS for the ready-to-inspect ???libbaz package libbaz, RFS it telling the plan package libbar, RFS it, repeating libbaz and still telling the plan package fooapp, rfs it, repeat the libbar and libbaz RFSs. Note that libraries are quite hard to test for a sponsor with just being a library package and some headers. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Requests to sponsor new library packages (was: why?)
On 2009-08-19, Ben Finney wrote: > Sune Vuorela writes: > >> For example, I would be very reluctant to sponsor a first package of a >> person that was a new library without any application using it, >> whereas a interesting kde application might easier catch my eye. > > That's interesting, thank you for that perspective. What do you propose, > then, for a maintainer who wants to get a new package into Debian, but > that package requires one or more separately-packaged libraries that > *also* need to be sponsored into Debian before the ???interesting??? package > can go in? Request sponsorship together. And read up on library packaging. Especially if this is ones first package in debian ever, you need extra reading, as libraries can be hard. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: why?
On 2009-08-18, Leinier Cruz Salfran wrote: > > --=-+HFkoxaqb4DFPsQ5uB2y > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > why is so hard to find a sponsor? > > I have a package online since 2 weeks ago, I sent 3 RFS and I have found > no sponsor yet. > > why It depends very much on the kind of package. Wether it is something that is "catchy" or not. Wether it is something a debian developer finds useful or not. For example, I would be very reluctant to sponsor a first package of a person that was a new library without any application using it, whereas a interesting kde application might easier catch my eye. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: rules file and missing dh_shlibdeps
On 2009-07-10, Jonathan Wiltshire wrote: > > --ibTvN161/egqYuK8 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri, Jul 10, 2009 at 11:26:04AM +0200, Adrian Stel wrote: >> And my question is: can i remove from rules file dh_shlibdeps line, with = > out >> any consequences ?? >> If not what problems I can encounter in the future. > > If your package is architecture dependent, you should keep the call to > sh_libdeps in case the upstream situation ever changes. If it's Arch: > any, you can safely remove the call. Wrong. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Packaging:library packaging stuff
On 2009-06-08, Adrian von Bidder wrote: > * how can I build the dependencies of the -dev package in a sane way? I'm= >=20 > sure creating them by hand is not optimal. (And I'm sure I've read at some= You need to create it by hand by looking at what includes is in *your* public headers. > time how to refer to my own version properly for the dependency of lib-dev= >=20 >=2D> lib, but I can't find it right now.) Depends: libfoo1 (= ${binary:Version}) And talking about depens, why is the dependency between the kpart packkage and teh library package unversioned ? > * after installing a KDE plug-in: is my guess correct that I can't really= >=20 > call kbuildsyocca4 since it needs to be called as user, not root? kded4 has a kdirwatch (inotify) watching the relevant dirs and runs kbuildsycoca4 as user when needed. It is also run on kde login. > * should I create a -dbg package? I've just included the debugging info i= > n=20 >=2Ddev right now since it's a small library, but I'm not quite sure. You at least need to get the -dbg package's dependencies right (by hand). My guess would be it needs kdelibs5-dbg and libqt4-webkit-dbg, else the backtrace will probably be of not much use. > > * How do I pass the right linker flags (-Wl,--as-needed?) through cmake to= >=20 > the linker? Whatever I tried so far, it was ignored and I get a few=20 > warnings from dpkg-shlibdeps. (This is more a question of style, since=20 > they're libraries I'd expect a KDE user has installed in any case.) -DCMAKE_LD_FLAGS="-Wl,--as-needed -Wl,-z,defs". Unless you know what you are doing, don't pass --as-needed with out --no-undefined. And you should not unless you really know why put the SOVERSION in the -dev package. I'm not sure that konq-plugin-webkit is a good package name, as I'm pretty sure it is not specific to konqueror in any way, but a more generic webkit based kpart. Unless you know that all libraries *will* change their ABI at the same time, you should not put several libraries in the same package. I so far haven't looked at anything but your email and the overview here http://ftp-master.debian.org/new/webkitkde_0.0.20090529svn974351-2.html /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: concordance
On 2009-06-04, Ben Finney wrote: > Mathieu Trudel-Lapierre writes: > >> I've applied the suggested changes to the files, and pushed it back on >> mentors.debian.net. It's using the same version number as before, just >> overwrote the files. Not sure if this is the preferred way to do this. >> I'm aware that it's definitely not the case in a "proper" repository >> :) > > For that very reason, I'm of the opinion that changes made after upload > to a public repository (and yes, mentors.debian.net is a repository) > should always be done in a new release of the package, just like it's > done with all Debian repositories. Mentors is not a public repository. it is a temporary staging area. > This view is not universally held, though. Check with the sponsor of the > upload; otherwise, read the arguments for and against and pick one that > makes sense. as I remember it, only one sponsor have expressed that he prefers the revision bumped each time. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: agedu
On 2009-05-29, Alexander Prinsier wrote: > PS2: for DD's, is it customary to upload a new version to unstable even > if it only fixes a small issue? Or should small issues be batched into > one update? Couldn't find an answer on this in the Debian policy. It depends. Especially it depends on the size (and buildtime) of the package compared to the size of the issue. I might upload some of my small packages for a typo fix in the description, whereas large packages that takes 2-4 days to build on a slower arch, and a 1-2 months release schedule only on rc bugs gets uploaded in between the upstream releases. (normally) /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: how to check for binary compability?
On 2009-05-25, Russ Allbery wrote: > The new version of the library is no longer exporting its internal > portability functions. This is good -- libraries should not export Only lurker is using this library. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Confused by .dirs, .install etc
On 2009-05-24, Jack Kelly wrote: > On Mon, May 25, 2009 at 9:40 AM, Sune Vuorela wrote: >> On 2009-05-24, Jack Kelly wrote: >>> On Mon, May 25, 2009 at 8:07 AM, Richard W.M. Jones >>> wrote: >>>> I have a problem building a library, starting with a dh_make template. >>>> The basic problem seems to boil down to files don't get moved from >>>> DESTDIR (debian/tmp) into the actual packages, so the final *.deb >>>> packages are empty. >>>> >>>> It seems like the .dirs and .install files in debian/ are >>>> something to do with this process. However I cannot find where in >>>> Debian policy these are documented ... >>> >>> My suggestion: If CDBS supports your package's build system, use it. >>> http://build-common.alioth.debian.org/cdbs-doc.html . It calls all the >> >> Please do not suggest debian/rules obfuscators, wether it is cdbs nor >> dh(1), to newcomers wanting to learn packaging. > > Okay, will do. Can you please explain your reasoning, though? On the > surface, it seems analogous to "Please do not suggest Makefile/sh > obfuscators, whether it is autotools nor cmake(1), to newcomers > wanting to learn how to build software.". How are you supposed to e.g. know that you migth need to pass options to dh_install if you don't even know what it is and that it exists ? /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Confused by .dirs, .install etc
On 2009-05-24, Jack Kelly wrote: > On Mon, May 25, 2009 at 8:07 AM, Richard W.M. Jones wrote: >> I have a problem building a library, starting with a dh_make template. >> The basic problem seems to boil down to files don't get moved from >> DESTDIR (debian/tmp) into the actual packages, so the final *.deb >> packages are empty. >> >> It seems like the .dirs and .install files in debian/ are >> something to do with this process. However I cannot find where in >> Debian policy these are documented ... > > My suggestion: If CDBS supports your package's build system, use it. > http://build-common.alioth.debian.org/cdbs-doc.html . It calls all the Please do not suggest debian/rules obfuscators, wether it is cdbs nor dh(1), to newcomers wanting to learn packaging. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Updated packge on m.d.n (was: RFS: kde-plasmoid-yawp)
On 2009-05-22, John Stamp wrote: > On Friday 22 May 2009 11:12:36 am Kai Wasserbäch wrote: >> Dear mentors, >> an updated package of kde-plasmoid-yawp has been uploaded to >> mentors.debian.net, the new dgetable URL is: >> http://mentors.debian.net/debian/pool/main/k/kde-plasmoid-yawp/kde-pl >>asmoid-yawp_0.2.3-2.dsc Plasma-widgets are not packaged in kde-plasmoid packages, but in plasma-widget-something, in this case probably plasma-widget-yawp How does this weather plasma widget differ from the two other we have in debian? (the one in plasma-widget-weather and the one from plasma-widgets-addons) > I'm not a DD, but I have a few comments about the packaging... > > dpkg-shlibdeps_fix_spurious_dependencies.patch: > > Why not add pkg-kde-tools to your Build-Depends? You can set > DEB_KDE_LINK_WITH_AS_NEEDED, plus you'll be using the same cmake setup > that all of the other KDE packages use. If you can fix the issues by fixing the build system instead of using --as-needed, it is much preferred to fix the build system (and send it upstream). But depending on which libraries that is spurious, it might be better to ignore it. for example, libgcc_s is unavoidable. > top_CMakeLists.txt_remove_FindPlasma_if-else-statement.patch: > > This patch seems to fix a problem that does not exist. You probably > don't even need to restrict to kdelibs5-dev (>= 4:4.2.0). Or am I > missing something? Plasma has changed quite a bit before and after 4.2.X, so I_think this simplifies it a lot. > > README.Debian: > > I'd remove it. It just duplicates info found in the description. Ack. /Sune - kde maint. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
On 2009-05-19, Matthias Julius wrote: > Barry deFreese writes: > >> Dmitrijs Ledkovs wrote: >>> I'm not a DD, but I think the correct way is to ping MIA team about it >>> and then after 2 weeks time you ping them again and they do a little >>> chat and come up with a solutions usally in your favor. Try that, >>> cause they record stuff in wnpp and then you can go on and adopt >>> stuff. >>> >>> i think the email was m...@debian.org but double check that >>> (Developer's Reference / New maintainer's guide one of them had a >>> chapter dealing with unresponsive developers.) >>> >>> >> The problem there is that you can't MIA a whole team. > > Especially since there are a number of active members. Unfortunately, > nobody seems to read the team's list or care to reply to mails sent > there. I don't know how close you follow debian development, but many members of the debian kde people have been quite busy over the last month trying to get kde in testing updated. We do all have a finite time, and krecipe has not been blocking anything for the work. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
On 2009-05-19, Matthias Julius wrote: > I just noticed that he actually cross-posted his messages to > pkg-kde-talk. There seems to be a little more human presence. Next > time I'll post there. That's *NOT* a sponsering list, but sending sponsoring requests there is the straight road into getting fully ignored. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: krecipes (updated package)
On 2009-05-19, Matthias Julius wrote: > I would really appreciate if someone could either help me to get my > krecipes package into Debian. > > I am just not quite sure whether it is OK to hijack a package like > that from an unresponsive packaging team. Should I ask QA to orphan > the package? KDE-Extra team has already said go ahead to at least one person being interested in taking over krecipes. (José Manuel Santamaría Lema) Most kde communication happens in irc channels. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: valkyrie
On 2009-05-08, LI Daobing wrote: > there is a proposed copyright format in [2], you also can use that format. > > [2] http://dep.debian.net/deps/dep5/ Note that this is just a proposal and many people don't like it, so please don't take it too serious. And some people won't sponsor packages with that format. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: questions regarding libmimelib1 as seperate source package
On 2009-04-25, Paul Wise wrote: > On Sat, Apr 25, 2009 at 3:02 AM, Jonas Meurer wrote: > >> I intend to maintain libmimelib1 as a seperate source package now that >> kdepim 3.5.9 has been removed from debian/unstable. > > What does lurker link against on other distros that have moved to KDE4? Ubuntu removed lurker from their releases. Fedora don't ship it. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: katimon
On 2009-04-17, Stefanos Harhalakis wrote: > Dear mentors, > > I am looking for a sponsor for my package "katimon". > > * Package name: katimon > Version : 1.0.2-2 > Upstream Author : me > * URL : http://www.v13.gr/proj/katimon/ > : also available from extragear/utils/katimon > * License : GPL > Section : kde Section: kde is for stuff that don't make sense outside the kde desktop. Currently, it is plasma widgets and the desktop itself (+ a lot of wrongly placed packages) Section: kde is not for anything that uses kde libraries. No need to add more to the wrong section. You probably want admin or utils. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
On 2009-03-21, Hideki Yamane wrote: > On Sat, 17 Jan 2009 12:42:43 +0900 > Junichi Uekawa wrote: >> > So instead of adding a package to be removed soon after it is clear of >> > NEW, I suggest not adding it at all. >> >> So, it's been two weeks, is there a working kde4? > > How's about korundum4 and kita packages' status? > Any progress? So now, when currently running mirror push is done, you have everything available in unstable. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Sponsorship requirements and copyright files
Hi! After a discussion on #debian-mentors and other places, I will not sponsor packages using the copyright file format described on http://wiki.debian.org/Proposals/CopyrightFormat It is a too complex, overengineered solution to a very minor issue. It is not easy readables for humans It is ugly Too time consuming to write and check No real gain. Discussions about this is welcome, but I think debian-devel is a better forum for that. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/control
On 2009-03-15, Laurent Guignard wrote: > On dim, 15 mar 2009 13:57:40 +0100, Jaromír Mikeš wrote: >> Hello, > > Hello, > >> >> I am not sure what to fill to "Section" in control file for my new package I >> am building. >> Program is small easy CLI utility generating sound (pink and white noise) >> >> Thanks for help >> > > For me this type of software has to be set in the "contrib" section, but i am > young in Debian and more experienced could confirm or not my opinion ! eh? contrib is for free stuff that has non-free build or runtime requirements. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: libv8: library without SONAME
On 2009-02-09, Antonio Radici wrote: > Hi, > as part of ITP #497701 I'm packaging libv8, a high-performance > java script library written by Google and used in Chrominum, the > open source version of the Chrome browser. > > The source code is taken directly from the SVN tags here: > http://v8.googlecode.com/ > It uses scons to build the library but the built library has no > SONAME, the only thing I get from scons is libv8.so. > > The ubuntu maintainer of libv8* packages asked the authors to add > the SONAME in november: > http://code.google.com/p/v8/issues/detail?id=151 > > So, my question is: how should I proceed? Stop packaging until the > SONAME is avaiable? Do as the ubuntu maintainer does? (libv8.so in > the libv8 package and the .h files in libv8-dev?) > > I've ready somewhere that /usr/lib should only contains libraries with > SONAME's, should I create /usr/lib/v8/ and put the library in there? (as > it was done with mozilla libraries?) you could just build it with 0d soname. (d as in debian) /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Closing bugs, incrementing release number, and uploads to mentors.debian.net
On 2009-01-19, Ben Finney wrote: > * When fixing bugs that prevented a previous release (e.g. one made to > mentors.debian.net) from making it into Debian (e.g. because the > sponsor requires further changes), recommended practice is to > increment the release number and make a new changelog entry, to > easily distinguish from any existing release. This is afaik only recommended if you want Neil Williams to sponsor you. If someone is working with me, this is absolutely *not* recommended. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
On 2008-12-29, Junichi Uekawa wrote: >> It needs more work than just change the dependencies to make it work >> with korundum4 > > Are we talking about a package which only exists in experimental > replacing the version in sid? Yes. and the replacement is planned ASAP. > Let the version which works today with a sid version, and make it work > with kde4 version when it's in unstable; does it sound reasonable? Well.. I think any work with the version that works with a sid version today is a waste of time - and if no one is planning to actually port it to kde4, someone will also have to, very soon, to ask for removal of it. So instead of adding a package to be removed soon after it is clear of NEW, I suggest not adding it at all. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
On 2008-12-28, Hiroyuki Yamamoto wrote: >>> How about kde4? >> >> KDE4 has nice ruby bindings, currently available in experimental. > > Oh, thanks. > When kde4 has entered in sid, kita2 should depend on korundum4 package. > http://packages.debian.org/experimental/korundum4 It needs more work than just change the dependencies to make it work with korundum4 /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
On 2008-12-28, Hiroyuki Yamamoto wrote: > Hi, > > Sune Vuorela wrote: >> On 2008-12-27, Hiroyuki Yamamoto wrote: >>> Upstream Author: Hideki Ikemoto >>> * URL: http://kita.sourceforge.jp/ >> >> Looking at this page, without much japanese knowledge, it looks like a >> kde3 application > > Approximately, no. > The upstream author says about the previous C++ version, > kita that will not correspond with kde4. > So, he introduced the new ruby version, kita2. > >>> * License: The MIT License >>> Section: net >>> Language: Ruby >>> Description: Ruby based 2ch client for KDE >> >> and the kde3 ruby bindings is planned to be discontinued in debian right >> after lenny release. >> >> Unless I'm mistaken about what it is using, I don't think uploading this >> to debian will serve much purpose. > > Hmm, kita2 can be used also with kde3 now. > The future, when the ruby binding of kde3 was lost, > the ruby binding programs will be embarrassed. If we are a bit optimistic about the release process and a bit pessimistic about time in NEW, I guess kita2 will enter debian around the same time as lenny gets released. > > How about kde4? KDE4 has nice ruby bindings, currently available in experimental. /Sune -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: kita2
On 2008-12-27, Hiroyuki Yamamoto wrote: > > Upstream Author: Hideki Ikemoto > * URL: http://kita.sourceforge.jp/ Looking at this page, without much japanese knowledge, it looks like a kde3 application > * License: The MIT License > Section: net > Language: Ruby > Description: Ruby based 2ch client for KDE and the kde3 ruby bindings is planned to be discontinued in debian right after lenny release. Unless I'm mistaken about what it is using, I don't think uploading this to debian will serve much purpose. /Sune > Kita2 is useful to view "2ch-style Bulletin Board System" that use > "bbs.cgi" and "read.cgi", it is like that we use RSS reader to read > blogs. It helps you to read/write articles in such BBS. > . > 2ch-style BBS include > - 2 channel (http://www.2ch.net, largest BBS in Japan) > - Pink channel (http://www.bbspink.com/) > - Machi-BBS (http://www.machi.to/) > - Shitaraba (http://rentalbbs.livedoor.com/jbbs/) and so on. > > > It builds this binary package: > kita2 - Ruby based 2ch client for KDE > > The package appears to be lintian clean. > > > The package can be found on mentors.debian.net: > - - URL: http://mentors.debian.net/debian/pool/main/k/kita2 > - - Source repository: > deb-src http://mentors.debian.net/debian unstable main > - - dget > http://mentors.debian.net/debian/pool/main/k/kita2/kita2_1.90.4-1.dsc > > Please get its source, check it and upload it. > > > Regards, > > - -- > Hiroyuki Yamamoto > yama _at_ gmail.com > yamamoto _at_ debian.or.jp > > -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Listing dependencies with specific versions
On 2008-12-09, Paul Wise <[EMAIL PROTECTED]> wrote: >> I doubt that - merely adding a new symbol is NOT a bug, let alone >> release-critical. > > Right, but not bumping shlibs at the same time is an RC bug AFAIK. I agree. /Sune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]