[00:13] <SpamapS> I have an old hard drive in storage that is running woody
[00:14] <SpamapS> Shut down my old home server and never turned it back on..
[00:52] <nh2> hi, I'd like to develop new features for rosetta (launchpad translations), but there are quite a lot of branches. Which one should I use as a base?
[00:54] <ajmitch> nh2: you'll want to talk to people in #launchpad-dev about that
[00:54] <nh2> ajmitch: thanks
[02:28] <achiang> hm, is there something else i need to do while testing X clients inside a chroot? i've exported my DISPLAY=localhost:0.0, and issued an xhost + in the host as well
[02:29]  * achiang decides to re-ask in #ubuntu-x
[06:34] <dholbach> good morning
[06:45] <kirkland> slangasek: what were those two packages?  for windows compilation?
[06:45] <kirkland> slangasek: mingw32 and nsis or something?
[06:58] <kirkland> slangasek: found them ...
[07:06] <pitti> Good morning
[07:14] <dholbach> hi pitti
[07:30] <pitti> hey dholbach, how are you?
[07:30] <dholbach> pitti, great - and you?
[07:31] <pitti> pretty well, thanks
[07:46] <pitti> Riddell: can you please review my apport, kerneloops, and cups uploads?
[07:46] <pitti> I'll take a look at the others
[07:47] <pitti> james_w: heh, seems we both uploaded a kerneloops for disabling for final
[08:16] <Riddell> pitti: ok
[08:17] <yao_ziyuan> when you release an alpha or beta, you're supposed to build apps with more debugging information, and therefore they would run slower than a final release, right?
[08:18] <pitti> yao_ziyuan: no, optimization/compiler settings don't change between alphas and release
[08:18] <pitti> yao_ziyuan: we strip off debugging information and publish them as separate pacakges on http://ddebs.ubuntu.com
[08:19] <yao_ziyuan> pitti: and this is since when?
[08:21] <pitti> yao_ziyuan: compiler switches -> always; ddebs> since 7.04 I believe
[08:22] <yao_ziyuan> thanks
[08:35] <YokoZar> cjwatson: new icoutils is now in the archive, if you want to utnubu that back to Debian that'd be fantastic
[08:36] <YokoZar> yao_ziyuan: individual packages can still tweak them though
[08:39] <tkamppeter_> mvo, hi
[08:57] <mvo> hey tkamppeter_
[09:03] <tkamppeter> mvo, in your update-manager fix for bug 647460, when you remove foomatic-db-gutenprint, do you replace it with ijsgutenprint-ppds?
[09:10] <mvo> tkamppeter: not yet, I prepare a update for this
[09:14] <tkamppeter> mvo, OK.
[09:22]  * samiz is away: Away
[09:26] <persia> !away > samiz
[09:37] <persia> Hobbsee, Your ideas are stronger than launchpad: ~ubuntu-universe-sponsors refuses to be deleted :)
[09:39] <Hobbsee> persia: hah
[09:39] <Hobbsee> take that, launchpad!
[09:39] <cjwatson> achiang: [[ isn't POSIX sh, no.  See https://wiki.ubuntu.com/DashAsBinSh which lists it.
[09:39] <cjwatson> YokoZar: thanks, will look after the maverick release
[09:46] <apw> cjwatson, have we done anything in our CD images to support EFI for maverick ?
[09:49] <Riddell> pitti: did you do two kerneloops uploads?  I accepted one but I don't know if it's the same one I looked at
[09:49] <pitti> Riddell: the other is from james_w; we can reject one
[09:50] <cjwatson> apw: yes, supported on amd64 only
[09:50] <cjwatson> apw: (sadly can't really test it on my test machine since am awaiting fixed firmware)
[09:53] <apw> cjwatson, there are reports that this is breaking mac's on boot (amd64 only, which now makes sense).  presumably this is something to do with how the CD ismade
[09:53] <apw> bug #633983
[09:53] <apw> so i presume this isn't going to be a kernel issue ?
[10:01] <cjwatson> apw: it's hard to say
[10:02] <cjwatson> apw: but, you know, there are reasons I left the i386 CD BIOS-only ...
[10:02] <cjwatson> apw: the only way to prove that it's specifically due to EFI support would be to remaster the CD without that
[10:03] <cjwatson> and there's very little we can do about this without removing EFI support, it's a catch-22
[10:03] <apw> cjwatson, and indeed they indicate the 32bit one does boot ok
[10:03] <cjwatson> but that's not really proof
[10:03] <cjwatson> would need to remaster the amd64 CD
[10:03] <apw> no indeed not anything more than indicative a test is appropriate
[10:04] <apw> is that someting one can do anywhere other than on the cdmaster machine?
[10:04] <cjwatson> sure.  loop-mount image on PATH.  genisoimage -r -V 'Ubuntu 10.10 amd64' -o maverick-desktop-amd64-remastered.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table PATH
[10:04] <cjwatson> actually you might need to loop-mount and then copy the whole thing
[10:05] <cjwatson> so: mount -o loop maverick-desktop-amd64.iso old-amd64; cp -a old-amd64 new-amd64; genisoimage -r -V 'Ubuntu 10.10 amd64' -o maverick-desktop-amd64-remastered.iso -cache-inodes -J -l -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table new-amd64
[10:05] <apw> cjwatson, ok so that sounds like something i can try and do ... people are targetting the kernel on this one and blaming me :/
[10:05] <apw> thanks
[10:06] <cjwatson> we could release-note "you have to use i386 on Macs"
[10:06] <cjwatson> not exactly ideal but ... dear Apple, please fix your EFI implementation
[10:07] <apw> cjwatson, well indeed, from the pointeres in the bug it seems even M$ cannot make ISOs which boot correctly on them
[10:07] <apw> cjwatson, so i suspect its going to be that in the end, i wonder if we could have ports cds
[10:07] <cjwatson> the eternal disk space pain
[10:08] <cjwatson> it's possible
[10:08] <cjwatson> probably, just about
[10:28] <bobba> Hi - I'm wondering where I should go to ask how I'd customise the installer? In particular, I'd like to know how I could remove EXT4 as an option for installations as I only wish to support installations on EXT3
[10:31] <cjwatson> 'rm /lib/partman/valid_filesystems/ext4' should be sufficient
[10:31] <cjwatson> (I think)
[10:32] <cjwatson> #ubuntu-installer is generally a better place to ask though
[10:32] <bobba> and then it should default to a different FS? because EXT4 is the default at the moment
[10:32] <bobba> ahhhh fantastic :)
[10:32] <cjwatson> er, yeah, you would need to change the default that's true
[10:32] <cjwatson> are you happy to rebuild packages to achieve this (more work, but more flexible), or do you want to just fiddle about with the live filesystem?
[10:33] <bobba> *nod* Well that's getting part way there which is further than I've got by myself ;)
[10:33] <cjwatson> the default filesystem is in debconf, as the default for the partman/default_filesystem question
[10:33] <bobba> Ideally I'd prefer to fiddle with the live system (of course...) but since I'll be building a fresh ISO then I'm happy to consider anything that's needed
[10:34] <cjwatson> well in that case you can edit /var/cache/debconf/config.dat and look for partman/default_filesystem
[10:34] <cjwatson> alternatively, add partman/default_filesystem=ext3 to the boot options
[10:36] <bobba> ahhh that sounds good - but I'd still have to change the life system to remove it from the valid list
[10:36] <bobba> fantastic though - I'm going to try that right away
[10:37] <cjwatson> right
[11:01]  * samiz is away: Away
[11:01] <nigelb> !away | samiz
[11:12] <Daviey> cjwatson: Can I ask you review a debdiff for bug #651027, please?  I just want to make sure i understood your suggestion.
[11:13] <Daviey> cjwatson: http://pb.daviey.com/vZXO/raw/
[11:14] <didrocks> hey, is there a release team member having some time to look at sync request in bug #651266 ? current plugin is broken as the feed change. I can do a fakesync if required
[11:14] <pitti> didrocks: looking
[11:14] <bobba> cjwatson, I've found the 05ext4 file to delete, but I was trying to change config.dat for the partman/default_filesystem setting to set it to ext3 - however, the config.dat doesn't seem to have the setting in? It just says "Name: partman/default_filesystem" "Template: partman/default_filesystem" "Owners: ubiquity".  I'm therefore clearly missing something :)
[11:14] <didrocks> thanks pitti ;)
[11:14] <OdyX> Hrm . How is it that pyside is in "pending publication" state for 3 days ?
[11:16] <bobba> cjwatson, sorry - I've figured it out!
[11:16] <bobba> thanks
[11:16] <pitti> didrocks: done; off to lunch now
[11:16] <didrocks> pitti: thanks a lot! enjoy your lunch :)
[11:18] <cjwatson> bobba: maybe templates.dat, I forget exactly
[11:18] <bobba> it is templates.dat - sorry for asking before actually looking deeply enough
[11:18] <cjwatson> Daviey: looks like what I meant, except that you removed "ChangeLog" from the dh_installchangelogs line which I don't think was intentional?
[11:19] <cjwatson> Daviey: I would have provided a diff but I hadn't test-built it and debdiffed the binaries to make sure they were coming out right
[11:19] <cjwatson> OdyX: because it's in the NEW queue
[11:20] <Daviey> cjwatson: Yeah, that wasn't intentional... My next step was to build and see - but i just wanted to make sure that is what you were thinking before i moved on.
[11:20] <OdyX> cjwatson: oh. "just wait" is the remedy to that, right ? :)
[11:20] <cjwatson> OdyX: correct
[11:20] <Daviey> cjwatson: Unless, you want to carry on with it?
[11:20] <cjwatson> Daviey: no, please go ahead
[11:20] <Daviey> ok, great.
[11:50] <ogra> i'm looking for an archive admin to review powervr-omap3, opengles-sgx-omap3 and devmem2
[11:59] <Daviey> cjwatson: For info - certainly looks like that debdiff (with ChangeLog added) fixed the issue - http://pb.daviey.com/1uDq/raw/
[12:02]  * Daviey hmmmmmmm's
[12:13] <cjwatson> Daviey: looks good, just check that the new dovecot-postfix's contents look sane and that none of the other packages have changed contents unexpectedly
[12:15] <Daviey> cjwatson: Yes, fair comment.
[12:16] <Daviey> cjwatson: Well there is another issue i'm fixing now with the depends of the transitional package.
[12:29] <ogra> doko_, the java buildd is ready for you, got instructions for lamont ?
[12:30] <doko_> Ng: is working on it
[12:30] <ogra> oh, ok
[12:30] <lamont> the instructions had better consist of "schedule the build on that box"
[12:30] <Chipzz> java buildd? ^^
[12:31] <cjwatson> Chipzz: bug 642344
[12:31] <lamont> Chipzz: newer hardware than what we have had
[12:31] <lamont> cjwatson: no
[12:31] <lamont> openjdk-6
[12:31] <lamont> at least I think so
[12:32] <ogra> right, bug 605042
[12:32] <Chipzz> lamont: when I saw java buildd, I was thinking along the same lines as "i386 buildd"
[12:33] <lamont> Chipzz: well, java is totally like its own architecture. that much is true
[12:33] <cjwatson> oh ok
[12:34] <Chipzz> lamont: well, yeah... when is ubuntu on java scheduled to be released? ;)
[12:34] <lamont> cjwatson: libspring was last seen waiting for RC to happen
[12:34] <lamont> Chipzz: hopefully not before I'm dead
[12:34] <cjwatson> lamont: RC has happened :-)
[12:34] <Chipzz> *grin*
[12:35] <Chipzz> lamont: my initial reaction to myself was: who has been smoking what kind of crack, and more importantly, where can I get some of that? ;)
[12:36] <lamont> cjwatson: yeah - I'm out of the loop on the ticket today
[12:36] <lamont> s/the/that/
[12:40] <apw> cjwatson, fyi i've built tested (it boots) and posted that remastered CD image for testing on the bug ...
[12:41] <cjwatson> ta
[12:42] <cjwatson> be sure to make it clear that this is not a fix we can simply roll into the distribution (because it breaks other things) but simply an attempt to narrow things down
[12:44] <apw> cjwatson, added a rider to it ... that is why i wondered if we might be wanting 'ports' style cd-image.  ones which arn't mirrored etc for the smaller corner cases like this
[12:44] <cjwatson> as I say, yes it's possible if there's no alternative
[12:44] <apw> probabally something that needs discussing in a more formal setting, to see what alternatives we have
[12:45] <cjwatson> we had an i386+mac port in the past for other reasons; the same kind of thing could be resurrected as amd64+mac
[12:45] <cjwatson> it's not even all that difficult
[12:45] <apw> apple sort out your firmware being the prefered option
[12:45] <cjwatson> quite, but Fedora have had the same problem for a while and obviously neither they nor MS have got anywhere
[12:45] <cjwatson> I shouldn't think "fails to boot non-Apple OS" is very high on Apple's priority list
[12:46] <apw> i would think "make sure it fails to boot non-apple OS" is high on their priority list
[12:46] <cjwatson> ultimately ... your hardware is hostile to other OSes, should have bought different hardware
[12:46] <apw> yep ... sadly
[12:46] <cjwatson> we can certainly try workarounds as long as they don't break other things
[12:46] <apw> not 'damn i can sell this sh*t to people who'll pay for an OS and not use it, sweet'
[12:47] <apw> cjwatson, anyway thanks for your help, i learned more than i wanted to about mastering CDs
[12:47] <apw> though one day when we arn't busy [sic] it might be nice to have the fulll incantations for the EFI ones too
[12:48] <cjwatson> same as before but add '-eltorito-alt-boot -efi-boot boot/grub/efi.img -no-emul-boot' before the path at the end
[12:48] <cjwatson> (ordering matters)
[12:49] <apw> yeeks thats an incation and 3/4
[12:51] <Riddell> mvo: any more uploads of update-manager planned?  I just made a small change
[12:57] <mvo> Riddell: yes, one for ebox-printers
[13:00] <ScottK> mvo: I noticed in http://www.mythbuntu.org/10.10/rc that they are telling people to remove the mythstream package.  Since it's not in the archive anymore, if they upgrade using u-m, then that's done automatically, right?
[13:03] <mvo> ScottK: yes, it will be suggested for removal at the end, if it causes problems during the upgrade I can make it go away earalier too
[13:04] <ScottK> mvo: I guess we should ask superm1 if it needs that.
[13:04] <ScottK> (hopefully he's an early riser and we'll know soon).
[13:04] <mvo> superm1: I can make mythstream go away earlier in the upgrade if it has the potential to cause trouble
[13:05] <mvo> ScottK: yeah, there is one other issues releated to gutenprint that I need to fix today too
[13:16] <Goodi> Hi! Would anyone know when/if the sun-java6-* packages will be available for Maverick?
[13:23] <diwic> Goodi, yeah, I've also been looking for them
[13:24] <Goodi> diwic-  I grabbed the lucid java, but that's not a real solution... There seems to very little info about it.
[13:25] <Goodi> I hope they keep it somewhere (partner repo is not optimal, but definetly better than nothing) so we don't need to start rebuilding it
[13:25] <ScottK> Goodi and diwic: It will be available in Partner
[13:26] <Goodi> great :)
[13:26] <Goodi> scottk - any deadlines/schedules (ie quesses) when it will appear there?
[13:26] <diwic> ScottK, good, do you know when?
[13:27] <Goodi> in stereo... where available :)
[13:27] <ScottK> No, you'd have to ask a Canonical person for details.  Partner is controlled by them and not part of Ubuntu development.
[13:28] <Goodi> ok. Hopefully they'll get it out before the 10.10 release :)
[13:28] <diwic> pitti, do you know who I should give a gentle push to make him/her put sun-java-* into the partner archive?
[13:29] <cjwatson> it's in NEW, I'll process it today
[13:29] <cjwatson> no need to push
[13:29] <diwic> \o/
[13:30] <diwic> finally
[13:30] <pitti> ah, ok; I thought archive admins aren't supposed to touch partner packages
[13:30] <diwic> pitti, who is supposed to touch partner packages? :-)
[13:30]  * cjwatson has no compunctions about doing so
[13:30] <cjwatson> anyway, nobody else other than archive admins can process partner packages through NEW :-P
[13:31] <pitti> diwic: I'm not sure, I think the other day there was some discussion between iamfuzz, bdmurray, and the archive admins that there needs to be some QA step before the AAs should accept it
[13:31] <cjwatson> it's gone through source NEW already ...
[13:31] <pitti> diwic: sorry, since I'm not an active archive admin, I'd rather trust cjwatson here
[13:31] <diwic> ok :-)
[13:32]  * diwic thought pitti was all-knowing :-)
[13:33]  * pitti ponders for a snappy answer about that being a contradiction to itself
[13:34] <pitti> "I don't know a puzzle which is so hard that I can't solve it" or something like that
[13:34] <diwic> pitti, then you can't be all-knowing, because then you would have known the snappy answer! Hah! :-)
[13:34] <pitti> diwic: q. e. d.
[13:35] <diwic> all right, let's get back to work
[13:48] <mvo> could someone eyeball http://paste.ubuntu.com/503887/ please?
[13:49] <pitti> mvo: I think you should also export LC_MESSAGES and LC_ALL
[13:49] <pitti> oh, and $LANGUAGES
[13:50] <seb128> pitti, LANGUAGE?
[13:51] <pitti> mvo: right, sorry; $LANGUAGE
[13:51] <pitti>        export LANG LANGUAGE LC_MESSAGES LC_ALL
[13:51]  * pitti sees this snippet being replicated all over the system
[13:53] <cjwatson> I'm surprised that /etc/pam.d/cron doesn't handle this
[13:53] <cjwatson> session       required   pam_env.so envfile=/etc/default/locale
[13:53] <cjwatson> perhaps only user cron jobs have a PAM session?
[13:54] <cjwatson> (if so, crontab(5) doesn't say that)
[13:55] <mvo> cjwatson: I was suprised as well TBH, but I did test and LANG was not set without that
[13:55] <mvo> pitti: thanks!
[14:01] <doko_> fluidsynth is another "nice" sync from experimental :-/
[14:05] <diwic> doko_, hmm?
[14:07] <doko_> diwic: look at the recent build failures of seq24, muse, fluidsynth, zynaddsubfx, xjadeo, lashwrap, ... on armel and powerpc
[14:10] <diwic> doko_, seems like you have a new one in queue?
[14:12] <doko_> diwic: are you involved with these multimedia updates?
[14:12] <pitti> Riddell: can we have daily CD builds again, to test the new langpacks, oversizedness, etc?
[14:12] <diwic> doko_, I've been developing fluidsynth for a year or two
[14:13] <diwic> doko_, and we don't have anybody upstream (or in Debian, IIRC) which tests armel
[14:14] <diwic> so armel is not supported by upstream (i e the FluidSynth community)
[14:15] <diwic> as for packaging of it, quadrispro did most of it but I helped some
[14:15] <doko_> diwic: maybe, but is this a reason to upload packages two weeks before the release which already fail to build in experimental, or show up as build failures in maverick? had this discussion yesterday with quadrispro ...
[14:17] <doko_> diwic: are the feature freeze exceptions for lash and fluidsync documented?
[14:17] <diwic> doko_, depends on which standpoint you have. Knowing what we did to improve stability (for supported platforms) in 1.1.2, I support having 1.1.2 in Maverick,
[14:18] <diwic> doko_, I don't know if quadrispro made any formal FFe:s.
[14:19] <doko_> diwic: fluidsync did build before, now it's not. see https://launchpad.net/ubuntu/+source/fluidsynth/1.1.2-2/+build/1982399
[14:23] <diwic> doko_, I'll see what I can do about it
[14:24] <doko_> diwic: one problem seems to be a missing b-d on libxml2-dev according to the build log
[14:32] <doko_> diwic: liblash-dev doesn't depend on libxml2-dev. don't know if devlibs:Depends is supposed to have this dependency. fixing it now directly
[14:33] <diwic> doko_, I was just about to come to the same conclusion, but I don't know much about those ${devlibs:Depends} variables to know if it should be listed there or not
[14:53] <pitti> cjwatson, dpm, Riddell: new langpacks built, they look fine to me; ready for the flood?
[14:54] <dholbach> pitti, dpm is travelling
[14:54] <cjwatson> it's ok by me
[14:56] <pitti> I'll accept them as they flow in
[15:45] <ogra_ac> gah, i'm screwed
[15:50]  * ogra_ac just noticed that tar xzvf arm-rootfs.tgz /mnt/> is not such a good idea 
[15:55] <pitti> ogra_ac: ? wouldn't that just try to extract "/mnt" from arm-rootfs.tgz?
[15:55] <ogra_ac> no, it in fact extracted the tgz to /
[15:56] <pitti> "oops"
[15:56] <amitk> ogra_ac: main devbox? ;)
[15:56] <pitti> weird that the "/mnt" parameter does that
[15:59] <rsalveti> ogra_ac: ouch
[16:01] <ogra_ac> hmpf
[16:08] <apw> anyone know if it is possible to tell apt-get to not check for or worry about disk space ?
[16:09] <cjwatson> apw: doesn't appear to be, from a glance at the code.  LD_PRELOAD statvfs? ;-)
[16:09] <apw> cjwatson, damn ... t
[16:10] <apw> thanks :)
[16:10] <ogra_ac> oh, i thought i'm screwed by killing my system disk and only being left with armel HW (and no cdrom) running ....
[16:10] <ogra_ac> but i'm screwed even more
[16:10] <ogra_ac> The following packages have unmet dependencies:
[16:10] <ogra_ac>  usb-creator-common : Depends: syslinux but it is not installable
[16:10] <ogra_ac> E: Broken packages
[16:10] <ogra_ac> gah
[16:11] <apw> ogra_ac, do i want to ask how you killed your system disk?
[16:11] <ogra_ac> i said how ... above
[16:11] <ogra_ac> i typoed a tar command
[16:11] <ogra_ac> tar xzvf arm-rootfs.tgz /mnt/>
[16:11] <ogra_ac> note the last char
[16:12]  * apw is supprised that is not an error in the shell
[16:12] <apw> ogra_ac, oh hmmm do you have network ?
[16:13] <ogra_ac> the tar ended with an error after extractinbg the whole think if that makes you happy :P
[16:13] <cjwatson> error in the shell> so am I.  perhaps you wewren't using bash
[16:13] <apw> http://kernel.ubuntu.com/~kernel-ppa/testing/
[16:13] <ogra_ac> i do have network
[16:13] <cjwatson> busybox sh doesn't like it either
[16:13] <ogra_ac> i surely was just using a gnome-terminal
[16:13] <cjwatson> -bash: syntax error near unexpected token `newline'
[16:13] <cjwatson> dash: Syntax error: newline unexpected
[16:13] <apw> http://kernel.ubuntu.com/~kernel-ppa/testing/ <-- there are .img files there which are bootable images which are DD able onto a stick
[16:13] <cjwatson> sh: syntax error: unexpected newline
[16:14] <ogra_ac> strange
[16:14] <cjwatson> all the shells I've tried fail
[16:14] <apw> not sure if they have any interactive mode thought, but i suspect you can init=/bin/bash them
[16:14] <ogra_ac> probably there was a special char behind it, thats all i got from shell history
[16:15] <xax200> Excuse me, what information should I know if I want to help implement client side decoration support in a window manager?
[16:15] <ogra_ac> apw, well, someone said i should be able to just dd the iso to usb key nowadays
[16:15] <sivang> hi all
[16:15] <ogra_ac> and given the download is done in 2min i'll know for sure by then
[16:16] <sivang> Is KDar not in the repositories anymore?
[16:16] <apw> usb-creator does do something using stuff on your system, whether its needed ... i don't know
[16:16] <ogra_ac> yes, i know
[16:16] <sivang> AFAIR it was in universe.
[16:16] <ogra_ac> but there was a mail thread recently about the possibility to dd
[16:16]  * sivang asks in -motu
[16:17] <apw> ogra_ac, well if it fails i know the .img files have been made such that they are bootable after a dd, some magic using a VM i am told to make them
[16:17] <ogra_ac> ok
[16:17] <ogra_ac> i'll fall back to them, thanks
[16:18] <apw> but they are special case images, so probabally need to hack them
[16:39] <ogra_ac> apw, so dd didnt work (indeed) ...
[16:39] <apw> pup
[16:41] <xax200> I don't usually find that dd'ing iso images to usb works
[16:42] <ogra_ac> well, the new syslinux is supposed to make that work
[16:43] <ogra_ac> but i guess my BIOS cant read iso9660 from usb
[16:43] <ogra_ac> or something like that
[16:44] <cjwatson> ogra_ac: bug
[16:44] <cjwatson> er
[16:44] <cjwatson> bug 524803
[16:45] <ogra_ac> ah, right
[16:45] <ogra_ac> i even know that one
[16:45]  * ogra_ac is totally off track after that disaster 
[16:47] <ogra_ac> erm
[16:47] <ogra_ac> why dont i use a netboot image
[16:52] <ogra_ac> heh
[16:52]  * ogra_ac hugs d-i
[17:10] <jibel> mvo, cjwatson, I reported bug 651325 against gnome-keyring during a wubi upgrade, the gnome-keyring is fixed but the unbootable problem still remains and can be reproduce.
[17:11] <jibel> I'll file a new report.
[17:11] <cjwatson> was your wubi install on a drive other than C:?
[17:11] <jibel> cjwatson, no
[17:12] <cjwatson> dunno then, my wubi upgrade recently worked fine
[17:12] <jibel> A few lines are displayed very quickly when I select the Ubuntu entry at the ntloader boot menu then there is a soft reset.
[17:13] <cjwatson> video them if you can
[17:13] <jibel> cjwatson, that's what I'm currently doing
[17:14] <cjwatson> did you 'dpkg --configure -a; apt-get -f install' etc. to get all the packages back into a sane state?
[17:15] <cjwatson> not that it *should* be needed but ...
[17:16] <jibel> fresh 10.04.1, update/upgrade, restart, update-manager -d, restart
[17:25] <cjwatson> jibel: well, I can give it a try here
[17:25] <cjwatson> jibel: nothing special beyond that?
[17:25] <jibel> cjwatson, error: unknown command 'loadfont'
[17:25] <jibel> error: file not found. (5 times)
[17:26] <jibel> error: unknown terminal 'gfxterm'
[17:26] <jibel> error: file not found
[17:26] <jibel> then the system restarts
[17:26] <jibel> that's all
[17:27] <cjwatson> hm, those are a bit crap but shouldn't really be fatal
[17:28] <jibel> cjwatson, a fresh install of 10.10 on the exact same system is working correctly.
[17:28] <cjwatson> I wonder what changed since my successful test
[17:29] <cjwatson> admittedly I didn't use update-manager because I wanted to force my local mirror, but that shouldn't have mattered
[17:29] <jibel> cjwatson, I can get the upgrade logs and see if I find something interesting.
[17:30] <cjwatson> well, I can just rerun here and see what happens
[17:31] <cjwatson> always optimal if a developer can reproduce locally
[17:39] <shtylman> sladen: I have already signed the agreement per my work with ubiquity
[17:39] <shtylman> that may ease some things
[17:40] <pitti> Riddell: since we now get new langpacks with empty update packs, ok if I add back some langpacks to the seeds?
[17:40] <Riddell> pitti: yes please
[17:41] <sladen> shtylman: do you now consider the Kubuntu logo  Author: Existing + Roman Shtylman   Copyright Holder: Canonical Ltd  ?
[17:42] <pitti> Riddell: I'll watch the dailies then; (are they re-enabled?)
[17:43] <shtylman> sladen: if that is what is needed then sure :)
[17:43] <shtylman> sladen: like I mentioned... I don't need to maintain copyright and it would make sense for canonical to have the copyright anyhow imho
[17:44] <sladen> shtylman: sooo, "yes" ?
[17:44] <shtylman> sladen: yes
[17:46] <jibel> cjwatson, I can't even mount the disk image, the file system is not recognized :/
[17:46] <cjwatson> uh
[17:46] <cjwatson> that's fairly spectacular failure
[17:46] <cjwatson> you didn't run out of disk space or something?
[17:47] <cjwatson> does Windows still boot?
[17:52] <Riddell> pitti: yes I re-enabled them about midday today
[17:53] <superm1> mvo, it won't cause problems earlier in the upgrade, it just will cause mythtv-frontend to not execute properly later on
[17:53] <superm1> mvo, so as long as it's removed later when update-manager recommends it to be gone, people should be fine
[18:09] <jibel> cjwatson, bug 653134
[18:10] <jibel> cjwatson, windows still boot
[18:11] <Lahtex> DEATH TO BAZHANG .. FUCKED UP MORON!
[18:11] <Lahtex> Freenode ....
[18:12] <jibel> cjwatson, and there's 43GB free (and I didn't ask wubi to create a root disk larger than than 43GB)
[18:12] <Lahtex> cjohnston: Do something or never come back....
[18:12] <Seeker`> !ops | Lahtex
[18:14] <cjwatson> jibel: ok, I'll see what it does for me
[18:14] <jibel> cjwatson, thank you
[18:15] <shtylman> hahaha
[19:23] <ogra_ac> cjwatson, any idea why the dd that zeroes the swap in user-setup-apply uses a blocksize of 16M ?
[19:23]  * ogra_ac wonders if thats mandatory
[19:35] <ScottK> mvo: Apparently extras.ubuntu.com is added to sources.list of servers too, but the keyring isn't seeded there, so one gets errors when updating.
[19:38] <cjwatson> ogra_ac: I don't know, but I'm guessing it's for speed
[19:39] <cjwatson> ScottK: ouch!  It's not meant to be
[19:40] <cjwatson> mvo: do you remember whether we decided to have apt-setup/extras default to false and be preseeded on for desktops, or default to true and be preseeded off for servers?
[19:40] <cjwatson> mvo: I think the former might make more sense since it should only be included when ubuntu-extras-keyring is
[19:50] <ScottK> cjwatson: I suppose I should file a bug report too.  What should I file it against?
[19:51] <cjwatson> ScottK: apt-setup (Ubuntu), and the ubuntu-cdimage project
[19:51] <ScottK> OK.
[19:56] <ScottK> cjwatson: Bug #653200
[19:57] <cjwatson> ta
[20:03] <sladen> shtylman: thanks, updated, process and forwarded!
[20:32] <mvo> cjwatson: I think the initial idea was exclude on server, but in the light of the seeding it makes more sense to set it to true on desktop only and default to false. will that be a problem for derivatives? or do they just inheritc from the generic "desktop"
[20:36] <ogra_ac> jdstrand, around ? i'm looking for an archive admin
[20:57] <paissad_> guys, i received this lintian warning 'missing-debian-source-format' ....  i don't know anything about quilt, i don't use it in my package ...i did not use it in the previous versions of my package & here is what i did --> echo '3.0 (native)' > debian/source/format ... do you think this good ?
[20:57] <paissad_> thanks in advance for helping
[20:57] <cyphermox> geser, I noticed you did a rebuild of gtkmathview because of libgdk_pixbuf2.0.la, could you review https://code.edge.launchpad.net/~mathieu-tl/ubuntu/maverick/aiksaurus/lp653217-rebuild or do the same rebuild for aiksaurus?
[20:59] <paissad_> btw, i have this other warning:
[21:00] <paissad_> W: pms-linux: executable-not-elf-or-script ./usr/share/pms-linux/resources/images/clients/musicpal.png
[21:00] <paissad_> i did in my debian/rules --> dh_fixperms /usr/share/pms-linux/resources/images/
[21:01] <paissad_> but i don't understand the reason why nothing changed !
[21:01] <cyphermox> paissad_, afaik, that's good for debian/source/format / missing-debian-source-format.
[21:01] <paissad_> i even did dh_fixperms only, but that did not change anything
[21:02] <paissad_> weird
[21:02] <cyphermox> paissad_, as far as executable-not-elf-or-script, did you copy these files from a ntfs or fat partition? this just means that file is marked executable and should not be
[21:02] <jdstrand> ogra_ac: sure, what do you need?
[21:03] <ogra_ac> jdstrand, three packages from NEW
[21:03] <ScottK> paissad_: The source format one is safe to ignore.
[21:03] <paissad_> cyphermox, those files are retreive (svn export) from a subversion server .. my system is ext3 ....
[21:03] <ogra_ac> jdstrand, powervr-omap3, opengles-sgx.omap3 (multiverse) and devmem2
[21:03] <paissad_> ScottK, you mean 1.0 instead of 3.0 ?
[21:04] <ScottK> paissad_: You can use whichever you prefer.  Nothing explicitly defined is 1.0, so if you want 1.0, it's not needed to add anything.
[21:04] <jdstrand> ogra_ac: these all have FFes?
[21:05] <ogra_ac> the bugs are mentioned in the changelog and ScottK looked over the FFes afaik
[21:05] <jdstrand> ogra_ac: k. I'll take care of it
[21:05] <ogra_ac> thanks !!!
[21:05] <ScottK> jdstrand: I gave him the "If you can find an archive admin to New it" sort of FFe.
[21:05] <ogra_ac> ubuntu ARM loves you :)
[21:05] <jdstrand> hehe
[21:05] <ogra_ac> (and asac too i guess)
[21:06] <ogra_ac> linaro is eagerly waiting for that stuff ... more than us actually
[21:06] <jdstrand> so linaro loves me too?
[21:06] <jdstrand> turning into a rather nice day :)
[21:09] <ogra_ac> jdstrand, yeah, the whole arm developer community will love you, these are the GL drivers for beagleboards, nobody ever shipped them in a painless way :)
[21:09] <jdstrand> \o/
[21:09] <jdstrand> sounds cool
[21:09] <ogra_ac> and TI managed to release them in a redistributable way just in time to make maverick the last minute
[21:09] <ogra_ac> yeah
[21:16] <geser> cyphermox: will do
[21:19] <cyphermox> geser, thanks!
[21:21] <paissad_> debian-watch-file-in-native-package
[21:21] <paissad_> what's a native package .. i don't really understand this ^^
[21:23] <kklimonda> paissad_: native packages are packages that debian/ubuntu is an upstream for.
[21:24] <paissad_> kklimonda, so created by debian ubuntu developers ?
[21:24] <kklimonda> paissad_: if you are packaging an upstream project you have to append a debian revision to it's version.
[21:24] <kklimonda> paissad_: yeah
[21:24] <kklimonda> its*
[21:25] <paissad_> kklimonda, i'm confused because, when i did not have the debian/source/format file, i had this warning
[21:25] <paissad_> 'missing-debian-source-format
[21:25] <paissad_> and now i created this file, i have this lintian warning
[21:25] <paissad_> debian-watch-file-in-native-package
[21:25] <paissad_> ^^
[21:25] <paissad_> well, i will remove the watch file then
[21:26] <paissad_> and this too -> native-package-with-dash-version
[21:27] <paissad_> really complicated & confusing the 'debian rules for packaging' .. that changes too often
[21:27] <kklimonda> what is the version of your package?
[21:27] <kklimonda> you can also run lintian with --info for a long description of this errors/warnings
[21:27] <paissad_> kklimonda, pms-linux-1.20.409+svn411
[21:28] <paissad_> kklimonda, in the changelog , i have -> 1.20.409+svn411-1
[21:28] <paissad_> kklimonda, i did lintian -iIEmv --color always --pedantic
[21:29] <paissad_> so i have explanations
[21:29] <kklimonda> paissad_: you should have 3.0 (quilt) in debian/source/format and an .orig.tar.gz in the parent directory.
[21:29] <paissad_> kklimonda, actually, i did (native) instead of (quilt) ...
[21:30] <paissad_> i will try quilt then
[21:31] <jdstrand> ogra_ac: I'm not keen on this udev rule in opengles-sgx-omap3: KERNEL=="pvrsrvkm", GROUP="users", MODE="0666"
[21:32] <ogra_ac> rsalveti, ^^^^
[21:32] <ogra_ac> jdstrand, what would you like 0660 ?
[21:32] <jdstrand> rsalveti, ogra_ac: is that required? wouldn't KERNEL=="pvrsrvkm", GROUP="video", MODE="0660" be better?
[21:33] <ogra_ac> do we actually still have a video group ?
[21:33] <jdstrand> ogra_ac: I would, yes, and a group that makes sense
[21:33] <rsalveti> if the video group is still working, np to use it
[21:33] <jdstrand> video:x:44:
[21:33] <ogra_ac> i guess ricardo took rthat over from an upstream doc or from openembedded
[21:33] <jdstrand> well, I am not up to date on the proper group
[21:33] <jdstrand> users seemed weird
[21:34] <rsalveti> I couldn't find a proper group to allow a normal user to use the 3d acceleration
[21:34] <ogra_ac> but that means tinkering with groups
[21:34] <rsalveti> didn't think that video would fit that
[21:34] <ogra_ac> yeah, video is rather for video devices
[21:35] <kirkland> slangasek: hey, upstart question for you ....
[21:35] <jdstrand> hmm
[21:35] <jdstrand> kees: ^
[21:35] <jdstrand> we should probably look at what nvidia does
[21:35] <kirkland> slangasek: so asking upstart for the "status" on a given process really just checks if the process is still running, right?
[21:35] <ogra_ac> yeah
[21:35] <rsalveti> do we have a /dev for nvidia?
[21:35] <jdstrand> I thought we did
[21:35]  * jdstrand doesn't have nvidia hardware
[21:36]  * rsalveti neither
[21:36] <kklimonda> yes, we do
[21:36] <kirkland> slangasek: i need to add some additional smarts, beyond whether the process is running, i need to check if it's actually doing something
[21:36] <kirkland> slangasek: ie, that it's not wedged in a while-true loop
[21:36] <kirkland> slangasek: what's the best way to do that?
[21:36] <jdstrand> I'll try to pull the sources and find it
[21:36]  * kees reads
[21:36] <kirkland> slangasek: in sysvinit script, the status action can be anything, in its own stanza in the case statement
[21:36] <kirkland> slangasek: how could i get something similar out of upstart?
[21:36] <jdstrand> kees: looking for the proper group for a udev rule for 3d graphics
[21:37] <ogra_ac> sigh
[21:37] <jdstrand> kees: it was 0666 with group 'users', I thought 0660 with something else, but am not up on groups for 3d
[21:37] <ogra_ac> the nvidia source is 50 meg
[21:37] <kees> jdstrand: the regular dri uses "video"
[21:37]  * ogra_ac twiddles thumbs
[21:37] <jdstrand> ah
[21:37] <jdstrand> I thought it did
[21:37] <kees> jdstrand: but gdm start-up set facls on console users too
[21:37] <ogra_ac> ah
[21:37] <kees> crw-rw----+ 1 root video 226, 0 2010-09-30 22:28 /dev/dri/card0
[21:37] <kenvandine> ev, ping
[21:37] <ogra_ac> then 0660 video it is
[21:38] <rsalveti> hm, then video it is
[21:38] <rsalveti> :-)
[21:38] <jdstrand> kees: thanks
[21:38] <kees> jdstrand: sure thing
[21:38] <jdstrand> $ ls -l /dev | grep video
[21:38] <jdstrand> crw-rw----  1 root video    10, 175 2010-10-01 10:35 agpgart
[21:38] <kees> it still might need facl-style stuff though
[21:38] <jdstrand> too easy
[21:38] <ogra_ac> lol
[21:39] <kees> $ getfacl /dev/dri/card0 | grep kees
[21:39] <kees> user:kees:rw-
[21:39] <kees> gdm or somebody does that, since I don't think the default users is in "video" any more...
[21:39] <kees> *user
[21:39] <ogra_ac> right
[21:39] <jdstrand> ah, seems not
[21:39] <jdstrand> (I am not)
[21:40] <ogra_ac> thats why i said above it would require tinkering with groups
[21:40] <kees> probably best to ask RAOF about it
"users" 0666 is certainly wrong though. :P
[21:40] <jdstrand> 0666 makes me pretty uncomfortable though
[21:43] <trijntje> is there a way to see in LP who imported a package (and translations) from upstream into LP?
[21:44] <slangasek> kirkland: 'status' returns the information upstart has about the status of the job; if you need some other kind of status check, I would recommend a standalone tool similar to apachectl
[21:44] <ogra_ac> jdstrand, uploading ubuntu2
[21:44] <kirkland> slangasek: :-/
[21:45] <slangasek> kirkland: not in an init script, because that will collide with all of the auto-mapping support between sysvinit and upstart
[21:45] <slangasek> kirkland: why do you have a server that can get wedged? :)
[21:45] <kirkland> slangasek: hmm, well, hard to answer that question in a politically correct manner
[21:46] <slangasek> kirkland: does this status check need to be integrated with something like heartbeat, though?
[21:46] <kirkland> slangasek: in any case, is it safe to say that moving a sysvinit script to upstart loses the ability to do a "smart" status check?
[21:46] <kirkland> slangasek: yes, something like heartbeat/pacemaker/etc
[21:47] <kirkland> slangasek: okay, so let's say I add something to service(8)
[21:47] <kirkland> slangasek: perhaps, "status+"
[21:47] <slangasek> kirkland: "safe to say" - I wouldn't say it that way because it casts it as an init system problem instead of a service problem, which is what I think bears the responsibility for not getting itself wedged
[21:47] <kirkland> slangasek: service <FOO> status+
[21:56] <jdstrand> ogra_ac: accepted
[21:56] <jdstrand> kees: thanks again
[21:56] <kees> jdstrand: np
[21:57] <ogra_ac> jdstrand, awesome
[21:57] <ogra_ac> thzanks !
[21:57] <andreserl> kirkland, just for clarification, but prolly you already know this, pacemaker has various ways of monitoring a service. One, would be by the use of sysvinit scripts, using the return codes of the scripts. Second, using upstart status output, which was recently added by Ante, Third, using OCF scripts, that what they basically do, is to monitor the application itself, however this is customizable  as long as you follow the standard for creating
[21:57] <andreserl> such scripts :)
[21:58] <jdstrand> hehe
[22:07] <rsalveti> jdstrand: cool, thanks :-)
[22:08] <jdstrand> rsalveti: sure :)
[22:25] <paissad_> guys, here is my debian/rules http://pastebin.com/LCb0Ggb9, there is dh_fixperms into it ... but i don't understand the reason why i get this warning with lintian -->executable-not-elf-or-script <-- AND indeed those files have their permissions not changed in the package
[22:25] <paissad_> where am i wrong ?
[22:26] <paissad_> i'm really confused .. i even added 'dh_fixperms' in other targets of the debian/rules file ... but nothing changed
[22:27] <paissad_> the build finished successfully ... but i have 3 warnings about executable files in /usr/share/pms-linux/ ....
[22:29] <cjwatson> dh_fixperms isn't entirely magic - if something is making the file executable, shove chmod -x in there
[22:30] <paissad_> cjwatson, i'm quite sure that dh_fixperms failed ^^
[22:30] <paissad_> i even can say i'm certain of this !
[22:30] <cjwatson> no
[22:30] <paissad_> cjohnston, it did not change the perms
[22:31] <cjwatson> read its documentation
[22:31] <cjwatson> it's not supposed to change *everything* - it fixes *certain problems*
[22:32] <paissad_> cjohnston, i did read the manpage already (before posting)
[22:32] <paissad_> it's a minimum :)
[22:32] <cjwatson> I am not cjohnston
[22:32] <paissad_> oh sorry !
[22:32] <cjwatson> the manual page does not say anywhere that it makes files under /usr/share non-executable
[22:32] <cjwatson> except doc
[22:32] <cjwatson> it's very specific
[22:33] <cjwatson> just insert chmod -x commands
[22:33] <cjwatson> you can also run with DH_VERBOSE=1 set in the environment to see exactly what debhelper commands are doing
[22:33] <paissad_> cjwatson, i thought about the chmod -x command ... but i just wanted to know the reason why dh_fixperms did not work in my case
[22:34] <cjwatson> because it can't realistically guess everything - files in /usr/share/PACKAGE are often meant to be executable
[22:35] <paissad_> cjwatson, ok
[22:39] <ari-tczew> cjwatson: are you a Debian Developer?
[22:41] <cjwatson> ari-tczew: yes, have been for ten years, why?
[22:42] <cjwatson> (well, thinking about it, that's exaggerating by a few months)
[22:42]  * maco rolls eyes
[22:43] <ari-tczew> cjwatson: I think whether you can apply this patch in Debian: debian bug 506083
[22:43] <cjwatson> Debian doesn't normally work like that.  You need to ask its package maintainer
[22:44] <cjwatson> oh, it's QA
[22:44] <cjwatson> yeah, guess I could, not tonight though
[22:44] <ari-tczew> cjwatson: would be nice if you add this one to your to-do ;)
[22:44] <cjwatson> it had a proper maintainer when I filed that bug
[22:52] <kirkland> RoAkSoAx: are you here?
[22:52] <RoAkSoAx> kirkland: yes
[22:53] <kirkland> RoAkSoAx: i know about those 3 methods...  there's just a "deficiency" we perceive in upstart's ability to test the real actual status of a service
[22:55] <kirkland> slangasek: okay, here's what I'm thinking ...  adding something to the service(8) command;  perhaps call it "status+", which first runs the status from sysvinit or upstart, but then executes (if available) something in /etc/status/$NAME, which is able to do "smarter" or "deeper" testing of the practical status of the service
[22:55] <kirkland> slangasek: for something like lighttpd, it's great that there's a pid for the process, but can wget retrieve a webpage from it
[22:56] <kirkland> slangasek: thus, you can define the real status+ of a service with something in /etc/status/lighttpd (as an example)
[22:56] <slangasek> kirkland: why under /etc/status instead of, say, /usr/lib/service/status/ ?
[22:57] <slangasek> putting it under /etc implies packaging overhead that seems avoidable here
[22:57] <kirkland> slangasek: sure -- that's fine
[22:57] <RoAkSoAx> kirkland: "pid for the process, but can wget retrieve a webpage from it" > that's exactly how the "monitor" option in a cluster would work, instead of just verifying if the service is running or not, which doesn't mean that it is receiving request in your example
[22:57] <kirkland> slangasek: i was thinking of symlinks in /etc, to stuff in /usr/lib, actually
[22:57] <kirkland> slangasek: that someone could break, or modify to their liking, if necessary
[22:58] <slangasek> kirkland: I wouldn't introduce the complexity of /etc/status until there was a demonstrable demand for it
[22:58] <kirkland> slangasek: ack, understood
[22:58] <kirkland> slangasek: what do you think of the nomenclature?  "service <FOO> status+" ?
[22:58] <slangasek> kirkland: otherwise, that seems ok - it'd be nice if this wasn't needed, using something like what RoAkSoAx suggests in its place, but I don't feel strongly about this
[22:59] <slangasek> kirkland: sees ok
[22:59] <slangasek> seems
[22:59] <kirkland> RoAkSoAx: okay, so how is your way done generically, for anything started by upstart or sysvinit?
[23:01] <RoAkSoAx> kirkland: from the cluster point, generically, it is just monitoring the return codes of sysvvinit, for start, stop, and status, and something similar is done for upstart
[23:01] <RoAkSoAx> but for examplke, if using OCF resource agents, we could monitor if the webserver is respoding to request
[23:01] <RoAkSoAx> for ex, from the apache OCF resource agent: " monitor:  return TRUE if the web server appears to be working. For this to be supported you must configure mod_status and give it a server-status URL.  You have to have installed either curl or wget for this to work."
[23:01] <kirkland> RoAkSoAx: right... okay;  here's the problem -- upstart's "status" is NOT sufficient (ie, it's not "smart" enough) for the test we need to perform
[23:02] <ebroder> Hmm...how do I make mountall interact nicely with encrypted swap? Right now I have a line in /etc/crypttab, and a line in /etc/fstab, but cryptsetup hasn't run before mountall does, so I get the "unable to find <my swap device>" error
[23:02] <RoAkSoAx> kirkland: if you need it for monitoring within an HA cluster, I'd suggest creating OCF resource agents
[23:03] <RoAkSoAx> kirkland: or providing the ability to upstart to do something similar, or either a tool that could do just that, monitor something specific
[23:03] <ebroder> Oh wait...maybe I screwed up my fstab
[23:03] <kirkland> RoAkSoAx: okay
[23:04] <RoAkSoAx> kirkland: is this for HA clustering?
[23:05] <slangasek> ebroder: yes, sounds like a busticated fstab; for encrypted swap, cryptsetup should run /well/ before mountall, i.e., in the initramfs
[23:13] <ebroder> slangasek: Yeah, I left out the second column in my swap line. My bad. Although I thought cryptsetup only ran for the root device in the initrd
[23:14] <RoAkSoAx> kirkland: if you need to take a look to some OCF resource agents, they are in "cluster-agents", inside heartbeat folder. Pacemaker also provides other ocf resource agents I believe
[23:14] <slangasek> ebroder: root device and swap, because you might hibernate/resume to swap
[23:14] <slangasek> to encrypted swap, I mean
[23:18] <ebroder> slangasek: Huh. That's clever
[23:37] <paissad_> damn it, i have to build a package for amd64 and for i386 archs, but i don't have currently an i386
[23:38] <paissad_> ^^
[23:44] <paissad_> is there a way to build a package for i386 from an amd64 arch ?
[23:47] <Daviey> paissad_: yes.. you can use amd64 to build i386, but tricky to do the other way around
[23:49] <Daviey> paissad_:  if you use pbuilder-dist.....  $ pbuilder-dist maverick i386 create   -> then $ pbuilder-dist maverick i386 foo.dsc
[23:52] <YokoZar> ArneGoetje: ttf-baekmuk and xfonts-baekmuk look like they contain the same thing -- should the latter package be dropped?